rspeedy/Lynx 应用包体积优化：先测量再按…

当需要分析并减小 rspeedy/ReactLynx 应用的 .lynx.bundle 体积、定位包为何变大、决定该拉哪个体积杠杆时使用。

适用场景

解决思路

1. 先验证再断言：不确定构建行为、分层、ES 目标或 stats/rsdoctor 输出时，去读源码（Rspack → Rsbuild → Rspeedy 三层，仓库分别为 lynx-stack、rsbuild、rspack、rsdoctor），按符号搜索而非凭命名或记忆推断。
2. 追踪真实模块图，绝不叙述式编造 import 链：构建时在 tools.rspack 中设置 optimization.moduleIds: 'named' 且 optimization.concatenateModules: false（scope-hoisting 会折叠 importer 边，必须关闭；会使体积膨胀约 +70%，仅用于分析，之后还原；de-concat 会禁用 __split__，需用真实构建交叉验证）。
3. 从 stats.json 的 reasons[].moduleName 读取真实 importer 边；大构建的 stats.json 可达数百 MB 到约 1 GB，不能用 readFileSync（ERR_STRING_TOO_LONG），要用 grep/readline 流式读取。

适用边界 · 注意事项

• 只优化运行时/渲染性能（卡顿、首屏慢、掉帧）——本技能只管发布字节，不碰执行速度。
• 处理 JS 内存/堆泄漏（用 lynx-js-heap-snapshot-analysis）、指令语义（用 reactlynx-best-practices）、深度 rsdoctor-data.json 取证（用 rsdoctor-analysis）、TS 类型/tsconfig（用 lynx-typescript）、解码 tasm 二进制格式（用 lynx-tasm-codec）。
• 在未做 per-module 测量前就执行用户指定的某个改动——即使已有粗略体积数字或用户明确要求某改动，也要先用 rsdoctor/stats.json 确认分解，若该改动是低 ROI 杠杆应先说明。

经验正文