微前端踩坑记录：错误处理 | 全网最详细

▌ 技术引导
微前端在实际项目中就像一辆半成品的车，你得自己补全所有零件才能跑起来。我见过太多人因为错误处理没做好，导致整个应用崩溃，甚至用户数据丢失。错误处理不是可选的，它是微前端稳定性的救命稻草。最常见的是子应用加载失败后，主应用不知道如何优雅地降级，或者子应用报错时主应用没有及时捕获并反馈。我用过一些工具，比如qiankun、single-spa，但它们都需要配合全局错误拦截机制。关键点在于子应用的生命周期钩子、全局错误监听器、以及子应用异常后主应用的兜底策略。如果你没处理好这些，项目上线后可能会被用户踩一捧一。

在具体操作中，我曾用qiankun的beforeLoad钩子做预加载校验，结果发现有些子应用因为依赖未加载而挂起，主应用不知道如何处理。后来改用fragment + manifest做依赖预分析，提前将资源下载并缓存。另外，子应用报错后，主应用不能单纯地弹窗提示，得把错误信息传到主应用的错误处理层，再根据错误类型做对应操作，比如切换到备用页面、记录日志、发送告警。如果错误发生在子应用的全局作用域，主应用没法直接拦截，只能用window.onerror或者window.onunhandledrejection做兜底。

还有个细节容易被忽略，就是子应用的异常可能影响主应用的资源加载，比如子应用报错导致主应用的某些资源无法释放。我在一个项目里，子应用在卸载时没有清理自己的资源，导致主应用内存泄漏，最终崩溃。所以，每次子应用卸载后，必须手动清理其注册的事件、定时器、服务等。错误处理也不能只停留在前端，得考虑后端如何配合，比如子应用挂起后，主应用应该怎么处理数据同步、状态恢复等一系列问题。

总之，错误处理是微前端项目的底线，没有它，你的项目就像在钢丝上跳舞，稍有不慎就掉下去。我用过多种方式，包括全局错误监听、子应用异常捕获、资源预加载校验、内存清理，还通过后端服务做异常日志聚合。这些经验都来自真实项目，不是纸上谈兵，也不是理论推演，都是我踩过坑、摔过跤、流过汗、才总结出来的。直接上干货，不讲花架子。

▌ 技术参考

一 微前端错误处理的核心逻辑
微前端错误处理的关键在于两个层面：子应用内部的错误捕获和主应用对子应用错误的全局拦截。子应用内部错误包括组件渲染失败、脚本加载错误、生命周期钩子异常等。主应用则要处理诸如子应用挂起、资源加载失败、卸载异常等情况。全局错误拦截可以通过window.onerror和window.onunhandledrejection实现，这两个钩子会捕获所有未处理的JavaScript错误。在qiankun中，可以通过registerMicroApps的beforeLoad配置项拦截子应用加载过程，提前检测资源是否存在。如果子应用内部有未捕获的异常，可以通过子应用暴露的error事件，将错误信息传回主应用。例如，启动子应用时添加监听：
```javascript
window.addEventListener('error', (event) => {
console.error('子应用错误:', event);
// 发送错误信息到主应用
});
```

二 全局错误拦截配置
主应用需要在全局级别配置错误拦截，特别是在微前端架构中，子应用独立运行，主应用无法直接访问子应用的上下文。使用window.onerror和window.onunhandledrejection是基本手段。以下是一个常见的配置方式：
```javascript
window.onerror = function(message, source, lineno, colno, error) {
console.error('全局错误:', message, error);
// 发送错误信息到主应用错误处理中心
return true; // 阻止默认错误处理
};

window.onunhandledrejection = function(event) {
console.error('未处理的Promise拒绝:', event.reason);
event.preventDefault(); // 阻止默认行为
// 处理错误逻辑
};
```
这种方式能确保主应用能捕获子应用的大部分错误。不过，某些浏览器或者某些JS运行时可能不完全支持Promise rejection事件，需要配合其他手段，比如在子应用内部使用try/catch或者使用错误边界（Error Boundary）框架，比如React的错误边界，或者Vue的全局错误处理。这些工具能帮助你捕获更细粒度的错误，避免整个子应用崩溃。

三 子应用错误上报与日志管理
子应用错误需要上报到主应用，否则你只能看到空白页面，毫无头绪。一个成熟的做法是，在子应用启动时，注册一个全局错误处理函数，并将错误信息通过fetch或postMessage发送到主应用。主应用在收到错误信息后，可以做进一步处理，比如日志记录、通知运维、页面降级等。例如，在子应用中添加如下代码：
```javascript
window.addEventListener('error', (event) => {
const errorInfo = {
message: event.message,
filename: event.filename,
lineno: event.lineno,
colno: event.colno,
error: event.error
};
postMessage('ERROR', errorInfo);
});
```
主应用对应监听这个message，然后进行处理。你也可以用类似的方式监听子应用的window.onunhandledrejection事件，并将相关信息发送给主应用。此外，日志记录建议使用统一的日志服务，比如Loog、Sentry或者自建的错误日志系统，确保所有错误信息集中管理。有些项目会把子应用错误和主应用错误统一处理，比如通过一个全局错误日志模块，或者使用微服务日志收集方案，这样能更高效地排查问题。

四 子应用异常处理的实战技巧
子应用异常处理不能只靠简单的try/catch，因为很多错误发生在子应用的生命周期过程中，比如挂载、初始化、渲染等。在qiankun中，可以通过beforeLoad、beforeMount、afterUnmount等钩子做异常处理。例如，在beforeMount中，可以检查子应用的状态是否正常，如果子应用加载失败，可以主动停止挂载流程，并提示用户。如果子应用内部有未处理的错误，可以在beforeUnmount中清理资源，防止内存泄漏。例如：
```javascript
registerMicroApps([
{
name: 'subApp1',
entry: '//subapp1.com',
container: '#container',
activeRule: '/subapp1',
beforeMount: () => {
// 检查子应用是否有异常状态
},
afterUnmount: () => {
// 清理子应用的资源
}
}
]);
```
需要注意的是，beforeMount和afterUnmount是异步操作，你需要确保这些钩子能正常执行，否则子应用可能会挂起。我见过不少项目因为钩子未正确执行，导致子应用异常后主应用不知道如何处理，最后只能让用户刷新页面。

五 子应用加载失败的兜底策略
子应用加载失败后，主应用应该有明确的兜底策略，而不是让页面空白。常见的做法是，主应用在加载子应用时，预加载资源，如果资源不存在或加载失败，就提示用户或者切换到备用界面。比如在qiankun中，可以使用fetch请求子应用的manifest文件，检查是否存在。如果不存在，就跳过加载，并在界面上提示错误。或者使用动态加载的方式，比如通过iframe或者script标签加载，如果加载失败，就直接渲染一个提示页面。例如：
```javascript
const subAppManifest = await fetch('/subapp1/manifest.json').then(res => res.json());
if (!subAppManifest) {
console.error('子应用manifest加载失败');
// 渲染提示页面
}
```
这样用户即使看到错误，也能知道问题出在哪里，而不是面对一片空白。另外，可以将子应用加载失败的情况记录下来，并在后续优化时做分析，避免重复出现。

六 子应用异常后主应用的恢复机制
子应用异常后，主应用不能直接崩溃，需要有恢复机制。比如，如果子应用因为某些原因无法加载，主应用可以尝试重新加载，或者切换到备用页面。在qiankun中，可以通过调用loadMicroApp方法主动重新加载子应用。例如：
```javascript
const subApp = getMicroApp('subApp1');
if (subApp && subApp.status === 'failed') {
subApp.load();
}
```
不过，这种方法并不总是有效，因为子应用可能已经初始化完毕，无法再次加载。所以，更稳妥的做法是，在子应用加载前做预加载，防止加载失败。如果预加载失败，就提示用户，而不是直接加载。另外，主应用可以设置一个恢复时间窗口，在子应用异常后等待一段时间再尝试恢复，或者根据错误类型做不同的处理。比如，如果是网络错误，可以重新加载；如果是资源错误，可以提示用户无法访问该模块。

七 脚本加载失败的应对方案
子应用的脚本加载失败是常见问题，尤其是在使用script标签动态加载的时候。我见过太多项目因为脚本加载失败导致整个页面崩溃，用户无法操作。解决方法包括：预加载脚本、设置超时重试、使用iframes做隔离、或者在加载脚本后检查是否加载成功。比如，在script加载完成后添加一个onload事件，如果失败则处理错误：
```javascript
const script = document.createElement('script');
script.src = '//subapp1.com/index.js';
script.onload = () => {
console.log('子应用脚本加载成功');
};
script.onerror = () => {
console.error('子应用脚本加载失败');
// 处理错误，比如提示用户或者跳转
};
document.head.appendChild(script);
```
还可以使用第三方库，比如LoadJS或者Webpack的异步加载机制，监控资源加载状态。如果脚本加载失败，主应用可以有相应的降级策略，比如不再显示该模块，或者使用备用页面替代。

八 子应用生命周期钩子的异常处理
子应用的生命周期钩子是错误处理的重要环节，比如beforeMount、mount、unmount等。这些钩子如果抛出异常，可能会导致主应用无法正常处理。比如，在qiankun中，如果子应用的mount钩子抛出错误，主应用会直接崩溃，用户看不到任何提示。因此，我建议在子应用的各个生命周期钩子中加入try/catch，并将错误信息上报到主应用。例如：
```javascript
const subApp = {
name: 'subApp1',
entry: '//subapp1.com',
container: '#container',
activeRule: '/subapp1',
beforeMount: () => {
try {
// 做一些初始化操作
} catch (error) {
console.error('子应用beforeMount异常', error);
// 上报错误
}
},
mount: () => {
try {
// 执行mount逻辑
} catch (error) {
console.error('子应用mount异常', error);
// 上报错误
}
}
};
```
这样即使某个生命周期钩子出错，主应用也能捕捉到，并做出相应处理，而不是直接崩溃。

九 子应用卸载时的异常处理
子应用卸载时如果没有正确清理资源，可能会导致主应用内存泄漏，甚至崩溃。例如，子应用可能注册了全局事件监听器、定时器或者side effects，如果卸载时没有清理，主应用会一直持有这些资源。我见过一个项目，子应用在卸载时没有移除监听器，主应用在后续加载子应用时反复注册，导致内存爆掉。解决方法是，在子应用的unmount钩子中，手动清理所有资源。例如：
```javascript
const subApp = {
name: 'subApp1',
entry: '//subapp1.com',
container: '#container',
activeRule: '/subapp1',
unmount: () => {
// 移除事件监听器
window.removeEventListener('error', handleSubAppError);
// 清理定时器
clearTimeout(timeoutId);
// 移除子应用相关的服务或依赖
}
};
```
此外，主应用在卸载子应用时，也要确保不会触发其他不必要的操作，比如全局状态的变更。如果子应用在卸载时触发了某些副作用，主应用应该能识别并做出隔离处理。

十 子应用异常导致主应用崩溃的修复
在某些情况下，子应用的异常会直接导致主应用崩溃，尤其是当子应用注入了全局变量或者执行了某些全局操作时。比如，子应用可能在window.onload中执行了某些逻辑，导致主应用的DOM操作失败。我处理过一个项目，子应用在mount时尝试修改主应用的某些DOM节点，结果因为主应用的节点不存在，导致子应用报错，主应用无法继续运行。解决方法是，在子应用的mount钩子中，先检查主应用的容器是否存在，再执行相关操作。或者使用iframe做隔离，确保子应用无法直接操作主应用的DOM。例如：
```javascript
if (!document.getElementById('container')) {
console.error('容器不存在，子应用无法加载');
// 不加载子应用，提示用户
}
```
还可以在子应用中使用polyfill或兼容性处理，避免因为浏览器差异导致的异常。此外，建议在子应用的入口文件中加入错误边界，比如React的ErrorBoundary或Vue的全局错误处理，避免子应用内部错误影响主应用。

十一 子应用异常后的页面降级策略
当子应用异常时，主应用应该有降级策略，而不是让用户面对一个空白页面。常见的做法是，在子应用加载失败后，主应用自动切换到一个备用页面，或者显示一个错误页面。例如，在qiankun中，可以通过配置加载失败后的回调函数，做页面降级：
```javascript
registerMicroApps([
{
name: 'subApp1',
entry: '//subapp1.com',
activeRule: '/subapp1',
loading: () => {
// 显示加载中页面
},
error: () => {
// 显示错误页面
}
}
]);
```
或者使用自定义的错误处理逻辑，在加载子应用失败后，主应用可以展示一个错误提示，比如“当前模块无法加载，请稍后再试”。还可以结合后端服务，当检测到子应用异常时，主应用自动刷新页面，或者切换到静态页面。这种方式能有效避免用户流失，同时也能让用户知道问题所在。

十二 子应用异常日志收集方案
子应用异常日志收集是微前端项目中不可或缺的一环。很多项目因为没有统一的日志收集，导致异常无法追溯，排查效率低下。我之前用过Sentry做错误日志收集，将子应用的错误信息发送到Sentry服务端，然后在主应用中查看。这种方式能自动收集所有未处理的错误，包括错误堆栈、发生时间、浏览器信息等。例如，在子应用中添加如下代码：
```javascript
const sentry = new Sentry.SentryBrowser({
dsn: 'https://example.com/dsn',
release: 'subapp1@1.0.0'
});

window.onerror = function(message, source, lineno, colno, error) {
sentry.captureException(error);
return true;
};
```
主应用也可以在加载子应用时，主动上报日志，比如在子应用加载失败时，主应用上报一个错误日志，记录发生时间、错误类型、子应用名称等。这种方案能帮助你快速定位问题，避免重复踩坑。

十三 子应用异常后的用户反馈机制
子应用异常后，用户需要有明确的反馈，而不是无感知地崩溃。我曾在项目中实现一个错误反馈弹窗，当子应用异常时，主应用会弹出一个提示框，告知用户哪里出错了，并给出解决方案。比如，提示“当前子应用加载失败，请检查网络或重试”。这种方式能提高用户体验，减少用户流失。在实现时，需要确保主应用能正确识别子应用异常，并触发反馈逻辑。可以使用一个全局的状态管理模块，比如Redux或者Vuex，记录子应用的异常状态，并在UI层显示对应提示。例如：
```javascript
const errorState = {
subApp1: false
};

// 异常处理逻辑
errorState.subApp1 = true;
// 在UI层展示错误提示
```
还可以在错误提示中提供操作按钮，比如“重试”、“查看日志”、“去官网反馈”等，这样用户能主动解决或反馈问题。这种方式在大型项目中特别重要，因为用户数量庞大，异常处理直接关系到品牌口碑。

十四 子应用异常后的资源清理与隔离
子应用异常后，主应用需要确保资源被正确清理，并且不会影响主应用的运行。例如，子应用可能注册了全局事件监听器、定时器或者某些DOM操作，这些都需要在子应用卸载时清除。我处理过一个项目，子应用卸载后，主应用依然持有该子应用的内存引用，导致页面卡顿甚至崩溃。解决方法是在子应用的unmount钩子中，手动清除所有资源。例如：
```javascript
onUnmount(() => {
clearInterval(timerId);
window.removeEventListener('click', handleSubAppClick);
// 清除其他资源
});
```
还可以使用iframe隔离子应用，这样即使子应用崩溃，主应用也不会受到影响。iframe的加载和卸载都是独立的，不会影响主应用的全局状态。这种方式虽然会带来一些性能损耗，但能有效隔离错误，确保主应用稳定运行。

十五 子应用异常后的性能优化建议
子应用异常会带来性能问题，比如错误处理不及时、资源未释放、页面卡顿等。我见过一个项目，子应用异常后，主应用无法及时清理资源，导致内存泄漏，最终页面崩溃。为了避免这种情况，建议在子应用异常处理中加入性能监控，比如使用Performance API记录从加载到卸载的耗时，并在异常发生时做对比。还可以通过资源预加载、动态加载、懒加载等方式优化加载效率。例如，在子应用加载前，使用fetch预加载资源，确保加载速度快。或者在子应用加载失败时，主应用直接跳过加载，避免不必要的资源浪费。这种方式不仅提高了性能，也增强了系统的稳定性。