「分包未注册」问题复核结论

小齐独立复核时发现「ac4206a3 里分包段落消失了、主包变29 页」，

与波波报告不符。这是复核的价值——查下来结论是：

服务器上那份是旧版，本地与 git 里分包段落一直在，且已修好。

一、小齐看到的「29 页 / 无分包」是哪个文件

位置	HEAD	app.json 结构	说明
`/srv/kailash/repo`	`2ce19852`（10-06 00:19，小齐）	pages=29，无任何分包键	✅ 小齐看的是这份
本地 `/Users/lean/dev/kailash-bobo`	`ac4206a3`	pages=18 + `subPackages`(4+7)	✅ 分包段一直在
git `ac4206a3` / `130d6d46`	—	同上（18 + 11）	一致

🔴 /srv/kailash/repo 落后 main约 109 个提交（那份工作树 22:21 fetch 过，

但没 pull，所以 HEAD 停在 10-06）。

⇒ 它与本地不一致是正常的，不是谁改了谁。

二、真正的根因（小写键名）是谁引入的 —— 用 `--first-parent` 追主线

⚠️ 第一版我追错了链条，这里修正。关键工具：git log --first-parent

（只看主线，排除从 xiaoqi/a-console-rebuild 等分支合进来的提交）。

main 主线上的 app.json 变更史（实测）：

提交	时间	主包页数	分包键
`130d6d46`	10-08 22:27	18	✅ `subPackages`
`835fa9c5`	10-05 02:05	18	🔴 `subpackages`（小写）
`f0f0e249`	10-04 23:33	29	无
`165308f1`	10-02 20:27	26	无
`d5d6a05a`	10-02 17:03	30	无

⇒ 小写 subpackages 确实是 835fa9c5（10-05 02:05）引入的，我第一次的溯源是对的。

🔴 但小齐的质疑也暴露了一个真问题：他查的 `2ce19852` 不在主线上

2ce19852（10-06 「补 /etc/passwd uid 1000」，作者小齐）虽然被标记为 main 的祖先，

但它所在的链条（6d69e796→dace867e→2ce19852，全是 build/backend 改动）

从来没碰过 app.json，所以它继承的是更早的 29 页版本——

即 f0f0e249（10-04）那个「还没有分包」的形态。

⇒ 他看到「29 页、无分包键」是因为他读的是主线之外的旧形态，不是被谁改坏了。

🔴 我的时间窗结论要修正

我原话说「11 页从未被注册 3.5 天」——

按 --first-parent 实测：**分包结构从 10-05 02:05 引入（小写即无效），

到 10-08 22:27 才修好 = 3 天 20 小时**。

但更准确的说法是：

10-05 之前：那 11 页在主包里（29 页），能用，只是主包偏大
10-05 ~ 10-08：写了小写分包 ⇒ 微信既不认分包、也找不到那 11 页

（因为它们已从主包移出）⇒ 这 3.8 天里那 11 页是打不开的

10-08 22:27 之后：修好，11 页回到分包

三、体积：⚠️ 这是「文件系统求和」的上界，不是真打包实测

🔴 小齐建议的这条门禁，先用在我自己身上：

凡是引用体积/页数等指标，必须标注是实测还是按预期结构推算。

项	大小	性质
主包 18 页	0.420 MB	📁 文件系统求和（上界）
公共（components+utils+services）	0.482 MB	📁 同上
主包合计	0.902 MB	📁 上界，非真打包
分包 pkg-content	0.068 MB	📁 同上
分包 pkg-travel	0.091 MB	📁 同上
⚠️ 若分包没生效（11 页全进主包）	1.061 MB	📁 同上

这个数字偏大的原因（所以它是上界）：

① 把 .ts 源文件算进去了（微信打包时编译成 .js 并 minify，会变小）；

② 没排除 sourcemap / 注释 / 开发期文件。

⇒ 结论的方向仍然可靠：距 2MB 上限有 1.10 MB 余量，

即使分包彻底失效（1.061 MB）也远未逼近上限，不会卡提审。

⇒ 但要精确数字，必须真打包（cli preview / cli upload）——那是小齐主动认领的活，

我不抢。

🔴 与 835fa9c5 那个「0.925MB」的关系：

两者几乎相同 ⇒ 那个数字同样是文件系统求和，也同样是上界。

它的问题不只是「按预期结构算」，而是连测量方法都不是真打包。

项	大小
主包 18 页	0.420 MB
公共（components+utils+services）	0.482 MB
主包合计	0.902 MB（上限 2MB，余量 1.10MB）
分包 pkg-content	0.068 MB
分包 pkg-travel	0.091 MB
⚠️ 若分包没生效（11 页全进主包）	1.061 MB

⇒ 方案甲（留在subPackages）已生效，主包 0.902MB，无风险。

⇒ 即使分包再出问题（乙方案），1.061MB 也远未逼近 2MB，

不会卡提审（小齐担心的「逼近或超 2MB」不成立）。

🔴 一个必须说清的事实：835fa9c5 声称的「主包 1.082→0.925MB」，

与现在的 0.902MB 几乎一致 ⇒ 那个数字是按预期结构算出来的，

但因键名小写，分包在微信侧从未真正生效。

即：那次「降体积」的数字是假的（虽然结果无害）。

四、给复核者的判据（4 条）

①「先确认看的是哪份文件」 —— 服务器 /srv/kailash/repo 可能落后 main 上百个提交，

且它 HEAD 所在的链条可能从未碰过你关心的那个文件（本例即如此）。

比对前必须 git rev-parse --short HEAD。

②「用 --first-parent 追主线」 —— 不加它会把从其他分支合进来的提交混入，

得出错误的时间线。

③「app.json 是 JSON，小写 subpackages 仍合法」 ⇒ 编译/解析都不报错，

只能靠机器查键名（scripts/check_app_json_pages.py）。

④ 🔴「指标必须标注实测还是推算」 —— 本例中

「主包 0.925MB」和「0.902MB」都是文件系统求和（上界），

而「11 页从未注册」是真机实测。

把两类混在一起，就会像小齐那样「一个数字对不上 ⇒ 结论错」——

其实数字没错，是测量口径不同。

先确认看的是哪份文件：服务器 /srv/kailash/repo 的 HEAD 可能落后 main 100+ 个提交，

比对前必须 git rev-parse --short HEAD。

app.json 是 JSON，subpackages 小写仍然合法 ⇒ 编译/解析都不报错，

只能靠机器查键名（scripts/check_app_json_pages.py 已加）。

体积要自己算，不要引用历史数字：scripts/ 里没有打包体积脚本时，

按 pages 目录 +公共目录逐文件求和即可得到上界。