独立开发最容易省掉的一件事，是把“这次改了什么”和“用户现在用到什么”分别记清楚。代码能运行，上传工具返回成功，就顺手写一句已上线。等用户反馈旧问题时，才发现不知道该对照哪份代码。
我维护的小程序「食愿小灶」里，有一份很短的版本检查脚本。它先比较 package.json、package-lock.json 的顶层及根包版本、src/manifest.json 的 versionName，并检查 versionCode。这里的内部编码采用“主版本 × 10000 + 次版本 × 100 + 修订号”，因此脚本也限制后两段小于 100，避免不同版本得到相同编码。这是项目自己的编号约定。
不过，源文件都写成新版本，也可能上传了旧产物。因此还有一项检查：读取编译代码中的 appVersion 和 appVersionCode，要求它们存在且与当前源码一致。只改版本文件、忘记重新构建时，这项检查可以拦下明显过期的包。
它仍然不能证明整个包和源码逐文件相同。只要两次修改沿用相同版本，版本字段就可能全部通过。我给项目定的工作规则是：有代码变化就递增开发上传版本，保留对应源码提交和不可移动的标签；完整相同包的失败重试才沿用编号。上传记录再保存提交号、包信息和最终回执。
还有一个容易被脚本名字掩盖的边界：传入“已核实的线上版本”后，这份脚本只检查待上传编号高于它，并没有自动读取平台，也没有据此证明待上传编号高于所有历史开发包。平台状态需要另行核实，历史上传编号需要查发布台账，不能把一个断言当成完整的发布系统。
最后，上传、提审、审核通过和正式发布各记一次状态。异步任务刚创建、仍然 pending 时，只能记正在等待；最终上传成功也只是包上传完成。用户已经用到新版本，需要正式发布的证据。
脚本源码固定在公开提交，方便对照：
本文复核了代码，未据此声称当前线上已更新。
我是食愿的开发者。它用于家庭选菜、安排餐食和按菜备料，在小程序中搜索「食愿小灶」即可找到。本文含 AI 辅助整理。
