版本号别乱写
很多人觉得版本号随便起个就行，比如从 0.9 直接跳到 1.0，听着挺正式。但用户看到 1.0 会默认这是稳定可用的版本。如果你的功能还不完整，bug 没清完，一上线就被打脸。建议遵循语义化版本规范，主版本号升级代表重大变更，别为了面子硬上。
先做一轮回归测试
开发过程中改了一个小功能，结果把登录页搞崩了，这种事太常见。发布前至少跑一遍核心流程：注册、登录、下单、支付这些关键路径不能出错。可以拉几个同事当小白鼠，用真实设备走一遍，比自动化测试更管用。
检查配置文件是否清理干净
开发时为了方便，可能在 config 文件里留了测试接口地址、调试开关或者本地数据库密码。一打包发生产，这些信息就可能暴露。尤其是前端项目，build 出来的 JS 里要是带着 console.log(API_BASE, \'http://localhost:8080\') 就尴尬了。发布前 grep 一下敏感词，比如 password、secret、localhost。
静态资源要带上哈希戳
HTML 引用的 JS 和 CSS 如果不加 hash，用户浏览器可能缓存旧文件，导致新功能用不了。构建工具一般都支持自动加 hash，比如输出成 app.abc123.js。这样每次更新资源名都变，强制刷新缓存。
<script src="/static/app.abc123.js"></script>
<link rel="stylesheet" href="/static/theme.def456.css">准备好回滚方案
哪怕测试再全，上线后也可能翻车。比如新接口响应慢，页面卡住。这时候得能快速切回上一个版本。如果是 Docker 部署，提前打好上一版镜像；如果是传统服务器，备份好旧代码包和数据库结构。别等到出事才想着怎么退。
通知相关方发布时间
运营、客服、第三方合作方都得知道你什么时候上线。特别是涉及接口变动的，对方系统可能依赖你的数据格式。提前发个邮件或在群里说一声，附上更新日志，避免半夜被 call 起来解释为啥订单同步失败了。
监控日志要开着
刚发布的版本最好盯紧点。错误监控工具如 Sentry 或 ELK 要确保能收到异常上报。如果用户反馈“提交按钮没反应”，你一看日志发现是某个 API 返回 500，就能马上定位问题。不然只能靠猜，效率低还容易扩大影响。