小程序上线后，那些没人告诉你的运维开销

很多朋友找我聊小程序，第一句话都是「做个多少钱」。我一般会先问一句：你是只算开发这一锤子，还是算它活着的这几年？前者好回答，后者才是真正让人头疼的地方。我自己手上维护着几个上线两三年的小程序，踩过的坑不少，今天就把运维这块的账摊开说说。

开发费是一次性的，运维费是月月见的

刚入行那会儿我也天真，觉得代码交付、审核通过、上线，项目就结束了。后来才发现，上线只是开始。小程序不像一个静态页面，它背后有服务器、有数据库、有第三方接口、有平台规则，任何一环动了，你都得跟着动。

我大致把运维开销分成几类，按我自己的经验排个序：

• 服务器与云资源：这是最稳定的一笔支出，也是最容易被低估的。
• 第三方服务续费：短信、地图、支付、推送、对象存储，单个不贵，加起来不少。
• 平台规则适配：微信时不时调整接口、审核策略、隐私协议要求，你得改。
• 故障与安全处理：半夜被告警叫醒这种事，做过的人都懂。
• 小需求迭代：老板或运营一句「能不能加个功能」，就是工时。

云开发到底省不省钱

这几年被问得最多的就是「用云开发是不是就不用管服务器了」。答案是：省了运维人力，但账单不一定更低。

云开发的好处很实在，不用自己配服务器、不用管扩容、不用折腾备案和证书，对小团队和独立开发者很友好。但它的计费是按调用量、存储、流量走的，业务量一上来，账单涨得比你想的快。我有个项目早期用云开发，日活几千的时候每月几十块，后来做了一次活动，流量翻了好几倍，那个月的账单直接让我愣了半天。

所以我的建议是：早期用云开发快速验证没问题，但要在后台把用量告警设好，别等到月底看账单才反应过来。业务稳定、量级可预期之后，再评估要不要迁到自建服务器，这笔账要算清楚，不能拍脑袋。

那些容易被忽略的固定支出

说几个具体的小钱，单看都不起眼，一年下来挺吓人：

• 短信验证码，按条计费，用户量一大就是持续消耗；
• 地图服务的逆地理编码、路径规划，超出免费额度就收费；
• 对象存储的流量费，图片和视频多的项目尤其明显；
• 域名、SSL 证书、备案相关的杂项；
• 如果用到了推送、客服、数据统计的第三方 SDK，很多都有年费。

我的做法是建一张「月度固定支出表」，把所有会扣钱的项列出来，每月对一次账。听起来土，但真能避免「这个服务什么时候开始扣钱的」这种尴尬。

真正贵的是人，不是机器

机器和带宽的钱其实可控，最难控的是维护的人力。小程序有个特点：它依赖平台，平台一变你就得动。微信调整隐私授权流程、改登录接口、收紧类目审核，这些都不是你能决定的，但适配的工时得你自己出。

我见过不少项目，开发时找外包做完了，上线后没人管，等到接口失效、支付出问题，才发现原班人马早联系不上了。这时候重新找人接手，读别人的代码、理清部署结构，成本往往比当初开发还高。所以我在报价时一直强调：把「上线后一年内的维护」写进合同，哪怕单独计价，也比事后抓瞎强。

几个能实打实降成本的做法

说点能落地的：

• 图片统一走 CDN 并压缩，别直接传原图，流量费能省一大截；
• 接口做缓存，能本地存的别每次都请求，既省调用费又快；
• 把日志和监控接上，出问题能第一时间定位，别靠用户投诉才知道；
• 非核心功能能砍就砍，功能越多，需要维护的面越大；
• 数据库定期清理历史数据，存储也是钱。

// 一个很土但有用的做法：给云函数加个简单的用量日志
// 方便月底对账时知道钱花在哪
exports.main = async (event, context) => {
  const start = Date.now()
  try {
    // ...业务逻辑
    return { ok: true }
  } finally {
    console.log(`[cost] ${context.function_name} ${Date.now() - start}ms`)
  }
}

最后说句实在话

聊小程序运维成本，不是劝你别做，而是希望大家在算预算时别只盯着开发报价。一个能活三年、五年稳定跑着的小程序，它的总成本里开发大概占一半，剩下的是持续投入。把这笔账提前想清楚，比上线后被动掏钱舒服得多。

如果你正准备做小程序，不妨先问自己三个问题：业务量大概什么量级、有没有人长期维护、平台规则变化谁来跟。想明白这三点，运维这块的坑能少踩一大半。