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

很多人以为小程序提审通过、点下「发布」就完事了。我做了六年独立开发，接过不少「上线后崩了」的救火单子，说句实话：真正花时间的地方，恰恰是上线之后那几个月。这篇就聊聊小程序技术运维里那些容易被忽略、但一出事就很要命的事。

一、先把「看得见」这件事做好

小程序不像 Web，用户手机上的报错你根本看不到。我的习惯是上线第一件事就把监控铺好：

• 用微信官方的小程序数据助手看基础指标，但它偏粗，只能看趋势；
• 接一个第三方错误监控（Sentry 之类的方案），把 App.onError 和 onUnhandledRejection 都挂上；
• 关键接口自己埋点，记录耗时和失败率，别等用户投诉才知道。

App({
  onError(err) {
    report(err) // 上报到自己的监控服务
  },
  onUnhandledRejection(res) {
    report(res.reason)
  },
  onLaunch() {
    // 记录冷启动耗时，对排查首屏慢很有用
    const t = Date.now()
    wx.nextTick(() => report({ type: 'launch', cost: Date.now() - t }))
  }
})

别嫌麻烦，这几个回调加起来不到二十行，救过我不止一次。

二、版本发布不是「一键」的事

小程序有个很坑的地方：用户本地可能缓存着旧版本，你发新版本后，有人打开还是老的。我的做法是强制检查更新：

const updateManager = wx.getUpdateManager()
updateManager.onUpdateReady(() => {
  wx.showModal({
    title: '更新提示',
    content: '新版本已准备好，是否重启应用？',
    success(res) {
      if (res.confirm) updateManager.applyUpdate()
    }
  })
})

还有一点：后端接口一定要做版本兼容。前端灰度期间新旧代码同时在跑，接口字段别随便删，加字段可以，删字段就是给自己挖坑。我见过一个团队直接把返回结构从数组改成对象，结果老版本用户白屏了整整一天。

三、云开发的运维误区

用云开发的小程序越来越多，很多人觉得「没有服务器就不用运维」，这是误解。云函数一样会超时、一样会打爆数据库连接数。几个实际经验：

• 云函数默认超时时间偏短，做批量处理记得在配置里调大，并且做好分页，别一次拉几千条；
• 数据库查询一定要建索引，尤其是按 openid 或时间范围查的场景，没索引的集合数据量一上来就卡；
• 定时触发器里的任务要幂等，网络抖动重试时别重复写数据；
• 云开发有资源配额，流量突然涨了会被限流，监控里要盯着调用次数和数据库读写。

我自己就踩过：一个活动页突然被转发爆了，云函数并发打满，用户全部转圈。后来加了本地缓存和请求合并才稳住。

四、性能是运维的一部分

上线后用户变多，首屏慢的问题会慢慢暴露。几个见效快的点：

1. 主包能小就小，图片、不常用页面全扔分包，主包控制在 1M 以内；
2. 列表页别一次渲染几百条，用 recycle-view 或者分页加载；
3. setData 是性能杀手，只传变化的部分，别整个对象扔进去；
4. 启动时别同步请求一堆接口，能并行的并行，能延后的延后。

记住一句话：用户感知的「快」，比代码写得漂亮重要得多。

五、留一手：回滚和应急

小程序没有真正的「回滚」按钮，但你可以提前准备：

• 保留上一个稳定版本的代码包，出问题能快速重新提交；
• 后端做开关（feature flag），新功能出问题直接关掉，不用等审核；
• 准备一个降级页面，核心接口挂了至少别白屏；
• 把审核周期算进排期，紧急修复也要留出半天到一天。

说到底，小程序技术运维不是一套工具，而是一种习惯：上线前想好会怎么坏，上线后盯着它怎么坏。做到这两点，半夜被电话叫醒的概率会小很多。