面试防线：SDK 异常劫持会不会影响主业务的正常请求
面试官提问：
“为了监控接口异常，你通过覆写全局的 XMLHttpRequest 和 Fetch API 来进行底层劫持（Monkey Patching）。这非常危险，如果你的拦截代理代码本身写出了 Bug 或者抛了异常，会不会直接导致用户的整个主业务请求失败、页面崩溃挂掉？”
核心回答思路 (STAR法则)
-
业务痛点 (Situation)
很多初级的监控脚本为了记录接口耗时，会粗暴地把原生的 fetch 替换成自定义逻辑。一旦他们的自定义代码抛出 Error，后续真实发送网络请求的逻辑就不会执行了。这会导致“为了安监控探头，把整个大楼的承重墙给敲断了”的恶性生产事故。 -
技术考量 (Task)
做基础设施底座的核心信条是“极度的无害性（Do No Harm）”。劫持逻辑必须完全在一个绝对隔离的安全隔离域内运行，不能对被代理的原生对象及其输入输出有任何一丝的污染和阻断。 -
架构决策 (Action)
- 全面包裹 Try-Catch 与静默失败：我在代理重写（Monkey Patch）函数的最外层，套了一层最高优先级的
try-catch。在这个 catch 块里什么错误也不向控制台抛，只干一件事：如果我的记录日志逻辑失败了，立即静默降级，确保紧接着原封不动地return nativeFetch.apply(this, arguments)回去。即便 SDK 自己烂了，业务侧的网络请求依然畅通无阻。 - 绝不篡改请求出入参与引用：我在拦截并读取接口耗时和 Response 状态码时，绝对不去消耗数据流（比如直接调
response.json()是大忌，会把真实的响应流读空导致业务方拿到 empty stream）。我只是读取只读的属性（如 status, url），如果要读取 body 我也会利用response.clone()克隆一份副本出来操作。 - 旁路分析不占主线程：所有采集到的耗时信息和接口路径，绝不在代理函数内部做复杂的归类和熔断计算。我仅仅是将一个结构体 Push 到一个内存队列中，然后立即结束拦截逻辑，交还控制权。真正的熔断策略和告警匹配，是在
requestAnimationFrame或是 Web Worker 这种后台旁路异步进行的。
- 业务价值 (Result)
依靠这种“如履薄冰”的极客级安全代理设计，这套劫持逻辑在集团几十个大流量应用里默默跑了两年多，在捕获了数十万次异常告警的同时，从来没有引发过一例因为监控 SDK 导致的白屏或接口故障，真正体现了“托底而不拖后腿”的基础设施价值。