微前端子应用崩溃后，错误上报归属、恢复粒度与宿主兜底 UI 怎么统一设计？

【背景】 我们是一个 B 端运营中台，React 18 + qiankun 2.x 微前端架构，宿主（Shell）+ 6 个子应用（订单、商品、营销、数据看板、审批、设置）。每个子应用独立发版、独立维护 Sentry 项目。日活约 800 运营同学，高峰并发 300+。

【现象（卡点）】

1. 错误重复计数：子应用 JS 崩溃时，错误同时出现在子应用的 Sentry 项目和宿主的 window.onerror 采集里（因为 qiankun 沙箱是 JS 沙箱 + CSS 沙箱，错误会冒泡到宿主 window），同一条错误被计 2 次，Sentry 里看到 47 条、实际只有 24 个用户受影响。
2. 恢复粒度粗糙：目前的做法是子应用 ErrorBoundary 捕获后直接 location.reload() 整页刷新，用户丢失宿主侧的导航状态和未提交表单（审批子应用有 10+ 字段的表单，刷新一次用户要重新填 3 分钟）。
3. 宿主兜底 UI 缺失：子应用崩溃后，宿主的 slot 区域变成一片空白（白屏），运营同学不知道是"加载中"还是"挂了"，工单量在崩溃时段翻了 4 倍（我们统计过 2 月一次 CDN 抖动，12 分钟内收到 31 条"页面白屏"工单）。

【已尝试的排查与结果】

• 在宿主 window.onerror 里加了 event.error.__qiankun_app_id 判断，发现 qiankun 并没有在 Error 对象上挂这个字段，只能靠 document.querySelector('[data-qiankun="xxx"]') 反推，不可靠。
• 试了 qiankun 的 addGlobalUncaughtErrorHandler 钩子，能拿到 appName，但 Sentry 的 beforeSend 里没法优雅地去重（两个项目是独立 DSN）。
• 恢复方案试了「只重载子应用」（qiankun unload → load），发现子应用内部 store（Redux/Zustand）没有持久化，重载后登录态和筛选条件全丢，体验比整页刷新还差。

【期望得到的答案形态】

1. 错误归属判定的具体规则：在 qiankun 2.x 下，怎么让"子应用错误只进子应用的监控、宿主错误只进宿主的监控"，有没有已验证的去重方案（比如 Sentry 的 event.contexts 打 tag 后在 query 层过滤，或者网关层统一收口）？
2. 恢复粒度的分级策略：什么级别用「子应用内部 ErrorBoundary 局部回滚」、什么级别用「qiankun unload→load 重载子应用」、什么级别才「整页刷新」？有没有团队做过这个分级并沉淀了判定标准（比如按错误类型：RenderError vs 数据层 Error vs 三方 SDK 崩溃）？
3. 宿主兜底 UI 的具体实现：子应用崩溃后，宿主 slot 区域应该展示什么（骨架屏 + 重试按钮？降级文案 + 客服入口？），有没有组件级的参考实现或设计 token 建议？

如果能给出「我们团队的具体配置 + 数据对比（崩溃率、工单量变化）」就更好，纯理论方案我也愿意听，但最好有踩坑细节。