背景
最近复盘了一个 Vue + wujie 的微前端项目。这个项目在高强度迭代后，首屏体验开始暴露出比较明显的问题：页面从打开到真正可用，中间有一段体感不太舒服的等待。
项目稳定后，我开始尝试做一轮性能优化。刚好那段时间我也在比较深度地使用 AI 编程工具，于是先让 GPT-5.4 分析主应用和子应用的加载链路，再基于它给出的方案逐项落地。
这次给 AI 的输入不只是一句“帮我优化性能”。我主要用了两类分析材料：一类是让 AI 直接阅读主应用和子应用代码，梳理启动链路和潜在瓶颈；另一类是导出浏览器 Network 记录，把请求耗时、资源体积和加载顺序一起交给 AI，让它从真实请求瀑布里辅助判断问题。
AI 在 plan 模式里给出的内容看起来很完整：拆包、懒加载、延后非关键逻辑、减少主子应用通信、优化加载时机、加缓存快照，基本每一条都像是性能优化文章里会出现的正经方向。
但真正实现和验证之后，结果并不理想。很多方案不是没打到瓶颈，就是只优化了指标表面，甚至还引入了额外复杂度。
这篇先复盘：AI 给了哪些建议，以及为什么这些建议看起来合理、落地后却没有明显收益。
AI 给出的优化方向
1. 显式 vendor 拆包
AI 的建议是对公共依赖做显式 vendor 拆包，把大块依赖从业务包里拆出来，降低单个 chunk 的体积。
预期收益看起来很明确：浏览器可以更好地缓存公共依赖，后续访问时业务包也会更轻。
实测之后发现，拆出来的很多依赖本来就是首屏必须加载的公共库。拆包以后单个文件确实变小了，但首屏请求数增加了，总加载链路没有缩短。
我的判断是：拆包本身不是问题，但不能只看 bundle 体积。对于首屏必需依赖来说，拆出去不等于变快，可能只是把一个大请求变成多个小请求。
2. 把 wujie 加载延后到首屏 mount 后
AI 的建议是把 wujie 的加载从同步调用改成首屏 mount 后再通过 idle 时机加载。
预期收益是让 DOMContentLoaded、FCP 这类指标更好看，主应用也能更快完成首次渲染。
实测结果确实会让部分指标变漂亮，但对用户体感帮助很有限。因为这是微前端项目，真正可用的页面通常要等子应用完成加载和挂载。微前端框架不加载，用户看到的只是一个更早出现的空状态或壳页面。
我的判断是：这类优化容易制造“指标变好”的错觉。微前端场景里，更应该关注子应用可见、可交互、关键数据渲染完成，而不只是主应用自己的 FCP。
3. 关闭大部分页面的 KeepAlive
AI 的建议是关闭大部分页面的 KeepAlive，理由是减少运行时内存和切页负担。
预期收益是降低页面驻留成本，让应用运行时更轻。
实测之后发现，这个方向和项目的默认交互预期并不匹配。项目本身就依赖页面保活来保持切页体验，而且当前瓶颈也不在 KeepAlive 带来的运行时负担。
我的判断是：性能优化不能只按通用经验套。KeepAlive 确实有成本，但它也承载了体验收益。如果瓶颈不是它，贸然关闭反而可能伤到已有交互。
4. 给主应用添加本地快照
AI 的建议是为主应用增加一层本地快照，用 sessionStorage 缓存部分前置配置，刷新时优先使用缓存结果，加快进入子应用的速度。
预期收益是跳过一部分重复请求，让刷新场景下更快进入子应用加载阶段。
实测下来，这个方案收益很有限。一方面适用范围比较窄，另一方面相关请求本身耗时不高。更重要的是，这类缓存一旦放宽使用范围，就需要额外处理权限和配置一致性风险。
我的判断是：缓存不是不能做，但要先确认它缓存的是不是瓶颈。如果缓存的是一个本来就很快的请求，收益会很小，复杂度却会实打实地增加。
5. 瘦身启动文件和公共样式
AI 的建议是把非首屏必需的库和样式改为懒加载，例如将 vxe 及其样式从启动链路里移出去。
预期收益是减少首屏资源体积和请求压力。
实测后，首屏加载大约减少了百 KB 级别的体积，也少了少量请求。启动文件整体约有 10% 的下降，但距离预期仍然有差距。
我的判断是：这是少数方向正确的优化，但它不是决定性瓶颈。它证明了资源瘦身有效，只是项目当前的首屏慢不完全来自这部分体积。
6. 子应用挂载前展示更轻的过渡状态
AI 的建议是在子应用挂载完成之前，先显示已挂载 iframe 或更轻的骨架屏。
预期收益是减少用户面对空白页面的时间，让等待过程更可感知。
这个思路本身是对的，后续也调整成了更明确的 loading 状态。
我的判断是：这类优化未必缩短真实加载时间，但能改善等待体验。它更偏体验兜底，不应该和真正的加载性能优化混在一起算收益。
7. 精简主子应用事件桥接逻辑
AI 的建议是清理主子应用之间没有实际使用的事件桥接逻辑。
预期收益是减少初始化阶段的冗余工作。
实测后没有看到明显变化。被清理的逻辑本身很轻，不构成主要瓶颈。
我的判断是：这种清理可以作为代码整洁度优化，但不能期待它解决首屏性能问题。它属于“顺手做可以”，但不应该被当成主线优化。
8. 延后非关键启动逻辑
AI 的建议是把部分非关键启动逻辑延后到首屏之后执行，避免阻塞子应用初始化。
预期收益是让首屏主路径更短。
实测下来，这部分逻辑并不是主要瓶颈，延后后对整体加载速度影响不明显。
我的判断是：延后执行的前提，是它真的阻塞了关键路径。如果只是看起来像“启动阶段的工作”，但实际耗时不高，调整顺序也不会带来多少收益。
最大的问题：指标口径不对
这轮复盘里最有价值的结论，不是某个具体优化点，而是我发现 AI 很容易把“通用性能优化建议”套到项目上。
这些建议单看都不离谱，甚至每一条都能讲出道理。但性能优化不是看方案是不是高级，而是看它有没有打中真实瓶颈。
尤其在微前端场景里，只看 DOMContentLoaded、FCP 或主应用 mount 时间是不够的。用户真正关心的是：
- 子应用什么时候可见
- 页面什么时候可交互
- 关键数据什么时候渲染完成
- 等待过程中有没有明确反馈
如果指标口径没有定义清楚，AI 很容易优化出一组漂亮但不解决问题的数据。
总结
这次的微前端性能优化整体跑下来，AI 给的方向看起来都挺像那么回事，但真正落地后，收益并没有想象中明显。很多方案都是“思路成立，效果一般”。
