小程序上线后，运维才是真开始

很多朋友以为小程序提交审核通过、点一下发布，这活儿就算干完了。说实话，我前几年也这么想过，直到第一个正式接的项目上线第三天，用户反馈“打不开”，我打开后台一看，云函数调用超时，接口报错堆了一屏。那一晚我才真正明白：上线只是起点，运维才是长跑。

这篇文章不聊虚的，就说说我这些年做小程序运维踩过的坑和现在固定用的一套方案，适合个人开发者和小团队直接抄作业。

先搞清楚：小程序运维到底在“运”什么

跟传统服务器运维不太一样，小程序的“黑盒”属性更强——代码跑在微信里，用户环境千奇百怪，你没法像 SSH 登服务器那样去看日志。所以运维的重点其实是三块：

• 可观测性：出问题时能不能第一时间知道、定位到。
• 稳定性：接口、云函数、第三方服务别掉链子。
• 迭代节奏：版本发布别把老用户搞崩，灰度要稳。

下面按这三块展开。

一、把监控和告警搭起来，别等用户来骂你

我最开始的做法特别原始：用户反馈了才去查。后来改成每天早晚各看一次后台，但依然被动。现在我的标配是三层监控：

1. 小程序后台自带的性能与异常数据

微信公众平台的“运维中心”和“性能监控”其实够用了，重点是每天扫一眼JS 错误率和接口失败率。这两个指标一抬头，基本就是有问题的前兆。

2. 自建轻量埋点

关键链路（登录、下单、支付回调）我会手动埋点，把结果上报到一个云函数里落库。代码不复杂，核心就是别让异常静默失败：

// 统一的上报方法，失败也不影响主流程
export function report(event, payload = {}) {
  wx.request({
    url: 'https://your-api.com/log',
    method: 'POST',
    data: { event, payload, ts: Date.now() },
    fail: () => {} // 上报失败就丢弃，绝不阻塞业务
  });
}

// 业务里这样用
try {
  await pay(orderId);
  report('pay_success', { orderId });
} catch (e) {
  report('pay_fail', { orderId, msg: e.message });
}

3. 告警通道

我用的最土但最有效的办法：云函数定时任务，每 10 分钟统计一次近半小时的错误数，超过阈值就推送到企业微信机器人。别小看这个，半夜接口挂掉能把你叫醒，比什么都强。

二、稳定性：几个必须做的兜底

• 接口超时和重试：wx.request 默认超时偏长，我一般设 8 秒，并对幂等接口做一次重试。
• 云开发环境隔离：测试环境和正式环境一定分开，别图省事共用一个数据库，我见过误删生产数据的惨案。
• 第三方依赖降级：地图、支付、短信这类外部服务，要有“失败提示 + 人工兜底”的方案，别让用户卡在空白页。
• 缓存策略：列表页数据用 storage 做短时缓存，弱网下体验差别巨大。

三、版本发布：灰度是保命符

小程序没有传统意义的服务器发布，但“分阶段发布”这个能力一定要用。我的习惯是：

1. 先发 10% 用户，观察 24 小时错误率；
2. 没问题再放到 50%，再观察；
3. 最后全量。

同时保留上一版本的代码分支，出问题能快速回滚。另外提醒一句，数据库字段变更要向前兼容，新版本加了字段，老版本用户还在跑，别让老代码读到 null 直接崩。

四、日常运维清单（建议收藏）

• 每天：看错误率、接口成功率、核心转化漏斗。
• 每周：清理无用云函数、检查存储用量和配额、看慢查询。
• 每月：复盘一次线上问题，更新告警阈值，检查证书和第三方服务到期时间。

运维不是堆工具，是建立“出问题能快速发现、快速定位、快速恢复”的肌肉记忆。工具只是辅助。

最后说句实在话，个人开发者精力有限，别一上来就搞全套 APM。先把错误上报和一条告警通道跑通，能让你在用户投诉之前知道问题，就已经赢过大多数人了。剩下的，随着项目长大再慢慢补。