# 1. Sentry 上报中的 beforeSend 钩子在脱敏敏感数据（PII、Token）的工程实践 A beforeSend 在事件发送到服务端之后执行，用于事后修复数据 B beforeSend 可在事件上传前修改或丢弃事件，是脱敏 PII 与 Token 的推荐位置 ✓ 正确答案 C beforeSend 返回 null 表示事件发送失败并触发重试 D beforeSend 中只能修改 message 字段，无法访问 contexts 与 extra
# 2. window.onerror/unhandledrejection/error 事件在前端错误埋点的工程取舍 A unhandledrejection 可以捕获资源加载失败的 error 事件 B 直接赋值 window.onerror 是推荐做法，不会被其他代码覆盖 C React 渲染错误会直接触发 window.onerror D addEventListener('error', fn, true) 在捕获阶段监听，既能捕获运行错误也能捕获资源加载错误 ✓ 正确答案
# 3. Sentry 与 Rollbar/Bugsnag 在 Source Map 上传与错误分组能力的工程取舍 A Sentry 提供构建期插件（如 @sentry/vite-plugin）自动上传 Source Map 并关联 release，分组定制能力强 ✓ 正确答案 B 三者都不支持 Source Map 上传，只能看到压缩后堆栈 C Bugsnag 的错误分组规则完全不可定制 D Rollbar 不支持与部署版本关联
# 4. 资源加载错误如何捕获（error 事件/资源 timing）并归因到网络/CDN/代码？ A 资源 error 事件可以拿到完整的 JavaScript 调用堆栈 B 资源 error 事件拿不到堆栈，需结合 Resource Timing 与按域名/路径聚合来归因网络、CDN 或代码问题 ✓ 正确答案 C 捕获阶段监听 error 无法捕获资源加载失败 D transferSize 为 0 一定表示资源被 CDN 拦截
# 5. Source Map 与版本关联的栈解析 A Source Map 上传后会自动匹配任何版本的错误，无需 release 标识 B Source Map 文件必须部署到 CDN 并允许浏览器直接下载 C release 只用于区分环境，与 Source Map 无关 D 客户端注入的 release 必须与构建时上传 Source Map 使用的 release 一致，栈还原才能成功 ✓ 正确答案
# 6. Sentry session-replay 与 RRWeb 的隐私保护工程价值 A rrweb 只录制控制台日志，不包含 DOM 交互 B 回放数据默认不含任何用户输入，无需脱敏配置 C Session Replay 通过 DOM 快照与增量事件录制还原操作过程，并用 mask/block 遮罩敏感内容实现隐私保护 ✓ 正确答案 D Session Replay 无法与具体错误事件关联
# 7. 跨域脚本错误为何只能拿到 Script error，如何用 crossorigin 与封装绕过并保留堆栈？ A 只要脚本标签添加 crossorigin 属性就能拿到堆栈，无需服务端配合 B "Script error." 只出现在 HTTP 协议下，HTTPS 下不受影响 C 跨域脚本错误被同源策略屏蔽，需 crossorigin 属性与服务端 CORS 响应头配合才能获取详细堆栈 ✓ 正确答案 D 捕获阶段监听 error 可以绕过该限制
# 8. Sentry 的 source map 上传策略（CI 注入 @sentry/vite-plugin vs 后台上传）在生产栈追踪的工程取舍 A @sentry/vite-plugin 只能在开发环境使用，生产环境必须后台上传 B 后台上传一定比构建期注入更可靠 C 构建期插件自动关联 release 并上传 map，后台上传解耦灵活但需自管版本一致性，两者可按场景组合 ✓ 正确答案 D Source Map 上传策略不影响生产错误栈还原
# 9. Source Map 与 X-SourceMap 头在 CDN 部署时的安全风险与替代方案 A X-SourceMap 头只影响服务器性能，不涉及源码泄露 B map 文件只有开发者工具能读取，普通用户无法访问 C 公开 CDN 上的 map 文件配合 X-SourceMap 头会被任意访客下载，建议构建期上传至带鉴权的平台并从公开目录删除 ✓ 正确答案 D 只要压缩混淆就无法从 map 还原源码
# 10. React 的 ErrorBoundary 与 Vue 的 errorCaptured/app.config.errorHandler 在错误捕获的边界 A React ErrorBoundary 可以捕获事件处理器中抛出的错误 B 框架错误边界可以完全替代全局错误监听 C Vue 的 errorCaptured 返回 false 会向上继续传播错误 D React ErrorBoundary 只能捕获子树渲染/生命周期错误，异步错误需全局监听兜底；Vue 的 app.config.errorHandler 是应用级最后兜底 ✓ 正确答案
# 11. try/catch 与 window.onerror 的边界——为何异步事件处理器内的错误需要全局兜底 A try/catch 可以捕获 setTimeout 回调中抛出的错误 B 有 try/catch 就不需要全局错误监听 C Promise rejection 会自动被 try/catch 捕获 D try/catch 只捕获同一执行栈内的同步错误，异步回调中的错误需 window.onerror/unhandledrejection 全局兜底 ✓ 正确答案
# 12. Service Worker 内的 self.addEventListener('error') 与 unhandledrejection 在离线缓存错误捕获的工程价值 A SW 运行在独立线程，需自建 error/unhandledrejection 监听并通过 postMessage 或 SDK 适配上报 ✓ 正确答案 B Service Worker 内抛出的错误会自动冒泡到页面的 window.onerror C SW 内无需捕获错误，浏览器会自动记录所有异常 D fetch 拦截失败不会发生在 Service Worker 内
# 13. Console.error 与上报系统的协作——开发环境 console 被禁用时上报系统的兜底 A console 可被覆盖禁用，上报系统应基于全局事件与 SDK 自建通道采集，console 仅作本地诊断出口 ✓ 正确答案 B 劫持 console.error 是上报系统最可靠的数据来源 C 禁用 console 不会影响任何错误监控 D 生产环境必须完整保留 console 否则无法监控
# 14. Sentry 的 Session Replay（基于 rrweb） A Session Replay 是录制屏幕视频流，与 DOM 无关 B Session Replay 默认录制所有输入内容并永久保存 C rrweb 以 DOM 快照加增量事件重建用户操作，回放与错误/性能事件关联分析，并需配置采样与遮罩控制成本与隐私 ✓ 正确答案 D 回放数据无需与错误事件关联
# 15. Source Map 的 #sourceMappingURL 与 Performance 监控在调试生产错误的边界 A Source Map 负责把压缩堆栈还原为源码行列，Performance 负责还原网络与渲染现场，二者互补构成完整调试链 ✓ 正确答案 B Performance 数据可以替代 Source Map 还原源码位置 C #sourceMappingURL 用于优化资源加载速度 D 错误调试只需要堆栈，不需要 Performance 数据
# 16. 错误聚合（@sentry/grouping-enhancements）的 fingerprint 在堆栈相似的工程价值 A 堆栈完全相同的错误根因一定相同，无需自定义分组 B fingerprint 可自定义分组键，grouping-enhancements 可按帧与异常信息精细改写分组，缓解堆栈相似造成的误聚合 ✓ 正确答案 C fingerprint 只影响告警通知渠道，不影响分组 D 错误分组规则无法覆盖第三方 SDK 帧
# 17. Sentry 与 OpenTelemetry 的事件关联（traceId/spanId） A traceId 与 spanId 无法注入前端错误事件 B 错误关联 trace 会增加大量重复数据，实践中应关闭 C 前端无法参与分布式追踪，trace 只存在于服务端 D 通过 trace 上下文注入与 W3C traceparent 传播，Sentry 错误可关联到前后端调用链，实现跨层根因定位 ✓ 正确答案
# 18. 浏览器 ErrorEvent 与自定义 Error 类（继承 Error）在堆栈信息保留的边界 A ErrorEvent 的 error 属性可能为空（如资源错误），自定义 Error 必须显式继承 Error 并经 super(message) 初始化，序列化时要显式提取 message/stack ✓ 正确答案 B 自定义 Error 类无需继承 Error，直接 throw 也能保留堆栈 C JSON.stringify 会完整保留 Error 实例的 stack D 资源加载错误的 ErrorEvent 总是携带完整调用堆栈
# 19. 前端脚本错误（Script Error）跨域（crossorigin script） A 添加 crossorigin 属性后无需服务端 CORS 头即可拿到完整堆栈 B "Script error." 只出现在 IE 浏览器 C "Script error." 是同源策略屏蔽跨域脚本错误信息的结果，需 crossorigin 属性与服务端 CORS 头配合才能解除，第三方脚本则做加载与可用性降级监控 ✓ 正确答案 D 捕获阶段监听 error 可绕过同源策略拿到跨域脚本堆栈
# 20. PWA Service Worker 缓存版本切换失败的 ErrorBoundary 与卸载策略 A SW 缓存版本切换不可能失败，无需兜底 B unregister 会永久禁用 PWA 功能，应避免使用 C 新 SW 激活后旧缓存可以立即删除，不存在错配风险 D 页面侧可用 ErrorBoundary 与版本信号做降级/刷新兜底，SW 侧用版本化缓存并存、失败终止切换与 unregister 回滚 ✓ 正确答案
# 21. error.cause（ES2022）在链式错误传递与现代监控的工程价值 A error.cause 可在包装业务错误时保留底层错误与堆栈，监控平台按根因展示与聚合，提升排障效率 ✓ 正确答案 B error.cause 只能挂字符串，无法保留 Error 对象 C 使用 error.cause 会丢失外层错误信息 D JSON.stringify 会自动序列化 Error 的 cause 属性
# 22. try/catch 中 caught error 在 Sentry 上报时丢失原始堆栈信息的 workaround A catch 后重新 new Error(message) 抛出能保留原始堆栈 B Sentry 会自动从字符串 message 重建堆栈 C 上报时应直接传递原始 error 对象，或用 error.cause 挂载原对象，避免重新包装与只传 message ✓ 正确答案 D 异步回调中上报永远不会丢失堆栈
# 23. ErrorBoundary 边界外的全局错误订阅（useEffect + subscribe）在第三方 SDK 错误的捕获 A 第三方 SDK 的错误一定会被 ErrorBoundary 捕获 B useEffect 中订阅全局 error/unhandledrejection 并在 cleanup 移除，可兜底第三方 SDK 异步错误，同时按来源归属与去重降噪 ✓ 正确答案 C 全局订阅只能捕获同步错误 D useEffect 订阅无需清理，React 会自动移除
# 24. Frontend Error Monitoring 与 APM 后端追踪（OpenTelemetry/zipkin） A 前端生成 traceId 并经 W3C traceparent 头传播给后端，错误事件携带 trace 上下文，即可实现前后端调用链关联与跨层根因定位 ✓ 正确答案 B 前后端 trace 完全独立，无法关联 C Zipkin 只支持前端数据，不支持后端 D 采样率不一致不会影响 trace 关联
# 25. Sentry 的 BrowserTracing 与 Web Vitals 联动的 INP/LCP 慢操作的根因定位 A BrowserTracing 只采集指标数值，无法定位慢的原因 B INP 慢与主线程无关，只需看网络 C 性能指标被建模为事务与 span，可沿瀑布拆解 TTFB、资源、长任务等维度，定位 INP/LCP 慢的具体环节 ✓ 正确答案 D Web Vitals 无法与后端 trace 关联
# 26. 错误监控与告警策略（PagerDuty/Slack Webhook） A 告警阈值固定为错误数 > 100 即可，无需调整 B 告警策略应分级（P0 走值班升级、低危仅汇总通知）、基于基线动态阈值，并对噪声与已知问题做抑制静默 ✓ 正确答案 C Webhook 集成只能发邮件 D 告警越多越能保障线上质量
# 27. Promise.reject 未捕获与 unhandledrejection 的浏览器兼容性差异与监控兜底 A 所有浏览器对 unhandledrejection 的行为完全一致 B 补上 catch 后 rejectionhandled 不会触发 C unhandledrejection 只能捕获同步错误 D Promise 被 reject 且未处理时触发 unhandledrejection，reason 可为任意值；浏览器实现有差异，监控需做序列化兜底并配合业务显式 catch ✓ 正确答案
# 28. 网络错误（fetch abort/timeout）vs 业务错误（API 返回 4xx/5xx） A 网络错误发生在响应建立前（abort/timeout/断网），业务错误由状态码或业务 code 表达，监控应按类型分类并差异化重试与告警 ✓ 正确答案 B fetch 返回 500 属于网络错误 C 4xx 错误一定需要自动重试 D AbortError 与超时无法识别
# 29. Source Map 在生产环境的部署策略与访问控制，如何在可调试性与安全性之间取舍 A Source Map 必须随 CDN 公开部署，否则无法调试 B 推荐构建期上传 map 至监控平台并从公开目录删除，必要时辅以鉴权访问与去除 sourcesContent，实现安全与可调试性兼得 ✓ 正确答案 C map 文件不含源码信息，公开部署无风险 D 访问控制会完全禁用错误堆栈还原
# 30. 微前端错误冒泡策略，子应用未捕获异常如何选择性上报并归属到对应应用/版本 A 微前端中所有错误都应归到基座应用 B 子应用错误无法携带版本信息 C 通过 SDK 上下文注入应用名/版本并依堆栈标识归因，按应用配置采样与去重，实现子应用错误的精确归属与选择性上报 ✓ 正确答案 D 全局监听必然导致所有错误重复上报
# 31. 针对第三方脚本（如广告 SDK）抛错的隔离上报与告警降噪 A 第三方脚本错误应与自有错误混在一起统一告警 B 静默第三方错误会导致完全无法监控 C 第三方错误无法识别来源 D 按域名/堆栈识别第三方错误并隔离到独立分组与阈值，配合聚合、静默与影响面监控实现告警降噪 ✓ 正确答案
# 32. 如何确保上报通道本身不会因该异常导致递归失败 A 全局错误处理器内抛错不会造成递归，无需防护 B 用 try/catch 包裹处理器、判重标记、节流退避与通道隔离，可防止上报自身抛错引发递归失败与请求风暴 ✓ 正确答案 C 上报失败应立即无限重试直到成功 D 监控组件抛错可以自由进入全局错误流
