小程序维护费用到底花在哪了

上周有个做餐饮的朋友问我，小程序上线之后每个月还要不要花钱。我说要，他愣了一下，说当初外包公司告诉他“做完就完事了”。这种误解太常见了，很多人把小程序当成一张海报，以为交付那一刻就结束了。实际上它更像一辆车，落地就开始产生养护成本，只不过有些费用你看得见，有些藏在水面下。

先搞清楚：维护费不是一笔固定的钱

经常有人问“小程序维护一年多少钱”，这个问题没法直接回答，因为维护费用是几个不同性质的开支叠在一起。我一般会把它拆成四块来看：

• 基础设施费：服务器、域名、SSL 证书、数据库，按月或按年扣
• 平台与资质费：微信认证、部分类目需要的资质年审
• 被动维护费：微信基础库升级、接口调整导致的适配
• 主动迭代费：你自己想加功能、改活动、调页面

前两块是硬性支出，跑不掉；后两块弹性很大，取决于你的业务节奏和当初代码写得怎么样。

基础设施：每月几十到几千都有可能

这块是最容易被低估的。一个纯展示型的小程序，用云开发的免费额度或者一台低配云服务器，一年几百块能搞定。但只要涉及用户登录、订单、图片上传，成本就上来了。

我经手过一个小电商项目，早期用云开发，用户量不大时很舒服，后来日活到了两三千，云函数的调用次数和数据库读写开始超免费额度，一个月账单从几十涨到四百多。这不是云开发贵，而是当初没做缓存和查询优化，每次列表页都把整张表扫一遍。

// 反面例子：每次请求都全量查，数据量一大就烧钱
const res = await db.collection('orders').get()

// 稍微改一下：加条件、加 limit、只取需要的字段
const res = await db.collection('orders')
  .where({ status: 'paid' })
  .field({ _id: true, amount: true, createdAt: true })
  .orderBy('createdAt', 'desc')
  .limit(20)
  .get()

同样的功能，写法不同，云资源消耗能差好几倍。所以基础设施费高低，一半看业务量，一半看代码质量。

微信认证与资质：小钱但不能忘

微信小程序认证费是 300 元一次，企业主体每年需要年审。金额不大，但漏了会影响支付、部分接口权限。另外像医疗、教育、食品这些类目，还需要对应的经营资质，资质本身有年审成本。这部分费用比较透明，没什么可省的，提前算进预算就行。

被动维护：最容易被忽略的隐性成本

微信基础库隔一段时间就更新，偶尔会废弃某些 API，或者调整授权逻辑。你的代码如果写得不规范，某天用户反馈“登录不了了”“支付调不起来”，你就得临时排查。

我见过一个项目，用的是很早版本的授权写法，微信调整后按钮点了没反应，开发者查了一整天才定位到。这种成本不会体现在账单上，但会消耗你的时间，或者你请人修的时候按次收费。

维护费用里最贵的往往不是服务器，而是“出问题时你找不到人”。

这也是我一直建议的：交付时一定要拿到源码和部署文档。没有源码，后面每一次小改动都得回头找原外包，价格由对方说了算。

主动迭代：真正的大头在这里

如果你的小程序是业务的一部分，那迭代是持续的。改个首页布局、加个优惠券、接个新的配送接口，这些都属于维护范畴。按人天算，一个熟练的开发者一天几百到一千多不等，具体看城市和复杂度。

这里有个省钱思路：把不常变的部分做稳，把常变的部分做成配置。比如活动页面的文案、图片、跳转链接，如果都写死在代码里，每次改都要发版；如果做成后台可配置，运营自己就能改，长期看省下的开发和等待成本很可观。

一个粗略的年费参考

• 展示型、几乎不迭代：服务器+域名+认证，一年几百到一千多
• 有交易、中等用户量、偶尔改版：一年三千到八千，含少量开发工时
• 业务依赖度高、持续迭代：一年一万以上，上不封顶

这些数字只是量级参考，别拿去跟报价单硬对。真正决定费用的是你的业务复杂度和你对“稳定”的要求。

几句实在话

谈小程序维护费用，别只盯着“一年多少钱”这个数字。先问自己三个问题：源码在不在我手里、服务器账号是不是我的、出问题有没有人能快速响应。这三件事理清楚了，费用才谈得有意义。

另外，签合同的时候把维护范围写清楚——是只修 bug，还是包含小功能调整，响应时间多久。很多纠纷不是因为钱多钱少，而是因为双方对“维护”这两个字的理解根本不一样。