小程序版本管理，别等上线才后悔

做小程序这几年，踩过最疼的坑不是性能，不是审核，而是版本管理。听起来像是个老生常谈的话题，但真到自己一个人维护三四个小程序的时候，才发现这事比想象中麻烦得多。

今天不聊大道理，就说说我自己在版本管理上吃过的亏，以及现在跑通的一套流程。

一开始我根本没用版本管理

刚做小程序那会儿，觉得代码量不大，改完直接点「上传」，填个版本号，提交审核，完事。微信开发者工具自带的版本号，我随手写个 1.0.0、1.0.1，有时候忘了改，连着传两次一样的号，工具也不拦你。

结果有一次，客户说线上有个页面白屏。我打开开发者工具一看，本地是好的。问题出在哪？我根本不知道线上跑的是哪一版代码——因为我本地已经改了好几轮，没打 tag，也没留分支，git 提交信息写的是「改改改」。

那天晚上我花了两个小时，靠人工比对文件才找到问题。从那以后我就老实了。

版本号到底怎么定

微信小程序的版本号是你在上传时自己填的，平台不强制规范，但这恰恰是坑。我的建议是老老实实按语义化版本来：

• 主版本号：大改版、重构、换 UI 框架时加一
• 次版本号：加新功能、加新页面时加一
• 修订号：修 bug、调文案、改样式时加一

比如 2.3.1，一看就知道是第二个大版本、第三批功能、第一次修补。别嫌麻烦，等你要回滚的时候就知道这串数字多值钱。

另外，微信后台的「版本管理」里会保留历史版本，但只有你上传过的。所以上传前一定确认代码状态，别把半成品传上去占坑。

分支策略：一个人也要有规矩

独立开发者常觉得分支是团队才需要的东西，其实不然。我现在固定三个分支：

main      → 线上稳定版，只接受合并
 develop  → 日常开发，随便折腾
 hotfix/*  → 线上紧急修复，从 main 拉

流程很简单：平时在 develop 上写，功能做完合并到 main，打个 tag，比如 v2.3.1，然后上传对应版本。线上出问题，从 main 拉 hotfix 分支改，改完合回去，再打 tag。

关键是 tag 和上传的版本号要一一对应。我现在的习惯是上传完立刻在 git 里打同名 tag，这样任何时候都能 checkout 到线上那一版。

体验版和审核版的坑

微信的版本体系分三层：开发版、体验版、线上版。很多人栽在体验版上——体验版是给测试和客户看的，但它指向的是你某一次上传的代码。如果你上传了新版本，体验版不会自动更新，得手动在后台切换。

我遇到过客户拿着旧体验版反馈问题，我对着新代码查半天查不出来。后来我养成习惯：每次上传新版本，第一时间去后台把体验版切过去，然后在群里说一声「体验版已更新到 x.x.x」。

还有审核版。提交审核后如果被拒，改完重新提交，版本号最好也升一下，别原地覆盖。这样审核记录和代码版本能对上，出问题好追溯。

回滚这件事，得提前想好

小程序有个好处，线上版本可以一键回退到上一个版本。但这只保一个版本，而且回退后你本地代码得同步回去，不然下次上传又乱了。

我的做法是：每次发版前，把当前线上版本对应的 commit 记下来，写在发布记录里。真出事要回滚，先在后台点回退，然后本地 git checkout 到那个 commit，拉个分支修，修完再走正常发布流程。别在回退后的线上版本上直接改，那样版本号就彻底乱了。

一点小建议

版本管理这事，说白了就是给自己留后路。小程序项目通常不大，但正因为不大，很多人懒得管，等到出事才发现连「上一版长什么样」都说不清。

如果你现在还是改完就传、传完就忘，不妨从今天开始做三件小事：规范版本号、上传前打 tag、发版留记录。花不了十分钟，但能省下好几个通宵。

毕竟，独立开发者最缺的就是时间，别把时间浪费在「我到底改了什么」这种问题上。