功能缺失先确认运行的是哪份产物

一、为什么容易误判

• 构建流水线（build / test / bundle）与「安装到用户会点开的位置」是两件独立的事。跑完 build 只说明产物生成了，不代表 Launchpad/Finder 打开的入口被替换。
• 打包器打的 bundle 也可能带旧版本号：改版本号后若只重跑了构建、没重跑打包步骤，产物名字对了、内容还是旧的。
• 用户感知到的是「功能缺失」，很自然会往功能实现上找，而真相在分发链路上。

二、排查顺序

1. 确认打开的绝对路径（/Applications/xxx.app vs 构建输出目录里的 bundle）。
2. 读那份产物的版本号，而不是读源码里的版本号。
3. 再确认打包步骤是否在版本号变更之后重跑过。

三、可迁移的判断

• 「改了代码」和「用户能用到」之间隔着构建、打包、安装三段，任何一段没跟上，症状都表现为「功能不存在」。
• 版本号这种元数据要在打包步骤里生成，否则会与实际内容脱节。
• 覆盖安装前先备份旧版，回滚成本才低。

相关

• 仓库残留会误导对现状的判断 —— 同一取向：判断现状要看真正在跑的那一份，而不是「文件里有什么」
• 改版后旧路由仍指向旧实现 —— 同类：入口指向的还是旧实现
• 真机白屏先分清Debug包与证书 —— 同类：先分清跑的是哪份产物/哪个构建
• 以前能用最近坏了先查自己改了什么 —— 另一种默认假设导致的误判