每次新版本上线，开发团队最怕什么？不是功能做不出来，而是明明一切正常，结果一上线就出问题。用户反馈崩溃、数据异常、界面错乱……这些问题往往不是因为代码写得差，而是发布前漏掉了关键检查项。
版本号别填错
看似简单的事，偏偏最容易出错。曾经有个项目，测试环境用的是 1.2.3，打包时手一抖写成 1.2.2，结果用户更新后发现啥都没变——其实是覆盖安装失败了。App Store 不允许低版本覆盖高版本，这一下就得重新打包提审，耽误三天。
建议在 CI 脚本里自动读取 git tag 或配置文件生成版本号，避免手动输入。
检查构建环境是否干净
本地改了一行日志没提交，顺手打了个包？危险！很多团队吃过亏：某个调试开关开着，上线后所有用户的请求都被打印到控制台，服务器日志瞬间暴涨几十倍。
发布前务必确认：
- 没有残留的 console.log 或 debug 开关
- 依赖库都是正式版本，不是本地 link 的 dev 版本
- 资源文件（比如图片、配置）已更新为最新
验证渠道配置
如果你的应用要上多个市场，每个渠道的 SDK 配置可能不同。小米需要推送权限，华为要用自己的统计，Google Play 又不能有国内 SDK。打包前不核对，轻则功能失效，重则被平台拒审。
可以建个 checklist 表格，每条渠道对应哪些配置项，勾完再打包。
别忘了检查文案和资源
有一次发布，首页按钮写着“立即体验（测试用）”，原因是设计师给错了切图，开发也没细看。等用户截图发到微博，才意识到大事不妙。
上线前最好拉产品、运营一起过一遍 UI，特别是弹窗、提示语、空页面这些容易忽略的地方。
API 地址切换了吗
测试时连着测试接口，一切正常。打包发布时忘了切回生产地址，结果用户打开全是空白数据。这种问题低级但高频。
推荐做法是在 build script 中根据环境变量自动注入 API 基础路径：
# 构建命令示例
npm run build --mode production
# webpack.config.js 中根据 mode 设置 base API
process.env.NODE_ENV === 'production'
? 'https://api.example.com'
: 'https://test-api.example.com'热更新脚本有没有冲突
用了热更新机制的项目尤其要注意。新版本已经发布了，但旧的热更补丁还在后台运行，可能导致页面加载混乱。
每次大版本发布前，把当前生效的热更策略停掉，确认无误后再重新启用，避免叠加影响。
留好回滚后路
哪怕检查了十遍，也难保不出事。发布前确保能快速回滚：备份旧包、保留旧版本构建配置、灰度发布先推5%用户。
曾经有个团队凌晨两点紧急回滚，结果发现没人记得上次发布的签名密钥存哪了，折腾一个多小时才搞定。从那以后，他们把密钥路径写进发布 checklist 第一条。
发布不是终点，而是新问题的起点。多花半小时检查，可能就省下后续三天加班。”}