北京小程序上线前，我踩过的部署坑

上周帮一位北京本地的客户把小程序推上了正式环境。项目本身不复杂，一个面向社区团购的小工具，但部署环节来来回回折腾了小半天。事后想想，这些坑挺典型，索性写下来，给准备在北京做小程序的朋友提个醒。

一、别把「开发版能跑」当成「能上线」

微信开发者工具里的开发版、体验版和线上版，环境是割裂的。最常见的翻车是：本地接口写的是 http://localhost:3000，一提交审核就白屏。北京这边很多客户有自己的机房或云服务，域名备案、HTTPS 证书这些前置条件要提前确认，别等到提审前一天才发现证书过期。

我的习惯是建三套配置：开发、测试、生产。用小程序的环境变量方案或者简单的配置文件区分，提交前用脚本检查一遍 baseURL，能省掉大量低级错误。

// config/index.js
const env = __wxConfig.envVersion; // develop / trial / release
const hosts = {
  develop: 'https://dev-api.example.com',
  trial: 'https://test-api.example.com',
  release: 'https://api.example.com'
};
export default { baseURL: hosts[env] || hosts.develop };

二、域名与备案，北京客户的常见卡点

微信要求所有请求域名必须在小程序后台配置，且必须是 HTTPS。北京的企业客户大多有备案域名，但要注意两点：一是备案主体和账号主体最好一致，二是域名要加到「request 合法域名」里，WebSocket、上传、下载域名是分开配的，漏一个就报错。

还有个细节：部分北京客户用的是老域名，SSL 证书链不完整，开发者工具能过，真机就报 net::ERR_CERT_AUTHORITY_INVALID。用 openssl s_client -connect 域名:443 检查一下证书链，比在真机上盲猜快得多。

三、云开发还是自建后端，先想清楚

如果项目是轻量级的，比如预约、展示、简单表单，微信云开发确实省事，不用管服务器和备案，部署就是点一下「上传并部署」。但云开发的冷启动和配额限制，在活动高峰期会露怯。北京一家做线下活动的客户，之前用云开发，报名开放那几分钟并发一上来，云函数就排队了，后来迁到自建服务才稳住。

我的判断标准是：日活低于五千、无复杂事务，云开发够用；涉及支付对账、高并发抢购，老老实实上自建后端。

四、提审前的那张检查清单

• 版本号递增，别重复提交同一个版本号
• 隐私协议、用户信息授权弹窗是否合规，这是审核驳回重灾区
• 测试账号要写进审核备注，尤其是需要登录才能看核心功能的
• 页面路径检查，删掉调试用的 console.log 和测试入口
• 真机预览至少覆盖 iOS 和 Android 各一台，北京客户常用机型差异不小

五、上线不是终点

发布之后，先在后台看「运维中心」的错误日志，前 24 小时多盯几眼。有次一个北京做教育的客户，上线第二天才发现某个安卓机型上富文本渲染错位，原因是用了不兼容的 CSS 属性。上线后的监控和灰度，比上线本身更值得投入。

知码客做北京小程序开发和 APP 定制这些年，越来越觉得部署这件事没有捷径，靠的是一份清单和一点耐心。代码写得好是基本功，能把东西稳稳当当地交到用户手里，才算完整。毕竟每一行代码，最终都是要和用户对话的。