Garfish 微前端加载慢该怎么优化？

Garfish 性能优化要分两段看：子应用加载前，重点是入口、资源、缓存和预加载；子应用运行后，重点是卸载清理、渲染开销、共享依赖和监控定位。不要一上来就堆 preload，真正有效的做法是先量化首屏、子应用加载耗时、资源体积和错误率，再针对瓶颈处理。微前端的性能问题经常不是 Garfish 本身慢，而是每个子应用都带一份 React、组件库和图表库，最后门户像同时打开了几个完整系统。

先把加载链路量出来

主应用应该记录从路由命中到子应用 mount 完成的耗时，并区分资源下载、脚本执行和渲染时间。没有数据时，优化很容易变成猜谜：有人说缓存，有人说分包，最后谁都证明不了收益。建议在 beforeLoad、afterLoad、mount 前后打点，并把应用名、版本、网络状态一起上报。边界是埋点不能阻塞加载，失败时要静默降级。

ts
const perf = new Map<string, number>();

Garfish.run({
  beforeLoad(app) {
    perf.set(app.name, performance.now());
  },
  afterMount(app) {
    const cost = performance.now() - (perf.get(app.name) || performance.now());
    report('garfish_subapp_mount_cost', { app: app.name, cost });
  },
});

资源体积和缓存怎么控？

子应用要做路由级分包，首屏只加载必要 chunk，大型图表、编辑器、地图组件延后加载。静态资源使用带 hash 的文件名，HTML 或 manifest 保持短缓存，JS/CSS 走长缓存，这样既能更新入口，又能复用稳定资源。取舍是缓存越激进，发布回滚越依赖版本管理；如果没有版本化入口，用户可能拿到新 HTML 加旧 JS。常见坑是所有子应用都打包同一套依赖，导致首屏下载重复，应该通过 externals、共享依赖或构建约束处理。

js
// nginx 示例：入口短缓存，hash 资源长缓存
location /app/index.html {
  add_header Cache-Control "no-cache";
}
location ~* \.(js|css)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

预加载不是越多越好

Garfish 可以在空闲时间预加载高概率访问的子应用，但预加载会占网络、CPU 和内存。更稳的策略是只预加载当前用户角色最可能进入的 1-2 个应用，并在弱网、低端设备或首屏未稳定时跳过。边界是移动端和海外网络下，盲目预加载可能让当前页面更慢。踩坑最多的是把所有子应用启动时一起 preload，看似后续切换快了，首屏却被拖垮。

运行时性能别忽略卸载

微前端页面切换频繁，如果子应用卸载不彻底，内存会慢慢涨，定时器和事件监听也会重复执行。React root、Vue app、全局事件、WebSocket、轮询、AbortController 都要在 unmount 里处理。取舍是生命周期代码会稍微啰嗦，但比线上定位“偶发卡顿”省事。边界是有些全局资源本来就该复用，比如登录态和主题，不要为了清理把共享能力也销毁掉。

追问

Garfish 加载慢时先查什么？

先查子应用入口是否慢、资源是否过大、是否重复下载公共依赖，再看脚本执行和渲染耗时。不要一开始就怀疑框架，因为很多慢是构建和资源策略造成的。取舍是网络层优化见效快，但如果 JS 执行太重，缓存再好也解决不了卡顿。边界是本地开发环境的耗时不能代表生产，需要看真实用户监控。

预加载应该按什么规则开启？

按访问概率、用户角色和设备条件来开。比如用户进入工作台后，大概率访问报表，就可以在浏览器空闲时预加载报表子应用。取舍是提前消耗资源换切换速度，适合高频路径，不适合所有路径。踩坑是忽略弱网和低端设备，导致当前页面交互被预加载拖慢。

共享依赖一定能提升性能吗？

不一定。共享 React、Vue、组件库可以减少重复下载，但会增加版本协调成本。取舍是稳定基础依赖适合共享，业务库或变化频繁的包不一定适合。边界是多个子应用依赖不同大版本时，强行共享可能引入兼容问题，比重复下载更危险。

如何避免切换页面后越来越卡？

重点检查 unmount 是否清理事件、定时器、订阅、WebSocket 和未完成请求。可以用 Performance 和 Memory 面板反复切换路由，看 DOM 节点和监听器是否持续增长。取舍是清理逻辑需要统一封装，否则每个子应用各写各的容易漏。常见坑是只卸载组件树，忘了组件外创建的全局副作用。

性能预算怎么定才合理？

不要拍脑袋定一个绝对值，要按业务场景、用户网络和设备分层。比如后台门户可以容忍首次进入稍慢，但应用内切换应该稳定；高频运营页面则首屏资源要更克制。取舍是预算太严会拖慢开发，太松又没有约束力。建议把入口 HTML、首屏 JS、子应用 mount 耗时和错误率纳入流水线或发布看板。