Garfish 的错误处理和降级机制是如何工作的？

Garfish 通过沙箱自动降级、生命周期错误捕获、资源加载容错三层机制保证微前端稳定性。

沙箱降级是核心。默认启用基于 Proxy 的 VM 沙箱，代理 window 对象隔离子应用全局变量，支持多实例并行。浏览器不支持 Proxy 时自动降级为快照沙箱——挂载前保存 window 全量快照，卸载后恢复原状，只支持单实例切换。降级过程对业务透明，框架内部自动判断。

生命周期层面，Garfish 在 beforeLoad、afterLoad、beforeMount、afterMount、beforeUnmount、afterUnmount 六个阶段提供钩子，任一阶段异常均触发全局 error 事件。主应用统一监听即可捕获所有子应用错误：

javascript
Garfish.router.on('error', (error) => {
  reportError(error); // 上报监控
  showErrorPage();    // 降级 UI
});

资源加载容错：Garfish 用 fetch 拉取子应用 JS/CSS，网络失败触发 afterLoad 错误回调。跨域动态脚本（JSONP 等）被转成 fetch 请求，后端未配 CORS 会报跨域错误。可用 excludeAssetFilter 放行特定脚本，但放行的资源会逃逸沙箱执行，副作用难以追踪。

追问

Proxy 沙箱和快照沙箱的核心区别？

Proxy 沙箱代理 window 读写，每个子应用有独立代理对象，支持多实例并行。快照沙箱在挂载时浅拷贝 window，卸载时还原，只能串行切换。Proxy 隔离更彻底但不兼容 IE；快照兼容性好但全局对象可能被意外修改。

子应用崩溃会拖垮主应用吗？

JS 错误被沙箱隔离，不会直接污染主应用状态。但 DOM 副作用可能逃逸——子应用在 document 上绑的事件监听器、插入的全局样式，卸载后不会自动清理。规范做法是在 unmount 钩子中手动移除副作用，或用 Garfish 的 DOM 沙箱自动收集和清理。

沙箱里 sourcemap 行号为什么对不上？

Garfish 通过 eval + sourceURL 执行子应用代码，sourceURL 改变了错误堆栈中的文件标识，导致行号偏移，sourcemap 还原指向错误位置。需要用 Garfish 提供的行号修正工具对齐偏移量。

excludeAssetFilter 放行的脚本出了问题怎么排查？

放行 = 脱离沙箱，脚本里的全局变量写入、事件绑定都不受管控。排查思路：在放行脚本的入口和出口打日志对比 window 差异；生产环境尽量不放行，让后端加 CORS 头保持资源在沙箱内加载。实际踩坑中，放行 JSONP 脚本导致全局变量污染另一个子应用的案例很常见。