简历追问：监控 SDK 架构与插件化设计

关联：全栈工程师简历 > 全链路埋点与监控 SDK、15分钟：前端埋点与监控 SDK。

对应简历描述

设计并实现了基于“核心包 + 适配包”的监控 SDK 架构，通过插件化机制支持多前端框架（React、Vue、Vanilla JS）无缝集成，并支持业务方高度自定义监控项与功能扩展。

面试官真正想确认

你是否理解基础设施 SDK 的“低侵入、可隔离、可卸载、可扩展”，而不是只封装一个 track() 函数。

连续追问链

1. 核心包与适配包

• core 包负责哪些能力：队列、上下文、上报、插件生命周期、错误隔离？
• React/Vue/Vanilla 适配包分别提供什么？为什么不能把框架逻辑放进 core？
• 初始化顺序如何设计？公共上下文、插件注册、自动采集谁先执行？

2. 插件机制

• 插件接口是什么：setup、teardown、onEvent、beforeSend、onError？
• 插件之间有优先级吗？一个插件报错会不会影响其他插件和主业务？
• 业务方自定义监控项时，是写代码插件、声明配置，还是两者都有？

3. 声明式埋点

• data-track-event 和手动 track() 的边界是什么？哪些事件必须手动声明？
• 事件委托绑定在哪里？React/Vue 动态渲染、弹窗、Shadow DOM、微前端会不会漏采？
• 事件语义如何稳定？按钮文案改了，业务事件 id 是否保持不变？

4. 多应用与版本

• 微前端主应用和子应用都初始化 SDK，会不会重复上报？如何做 namespace 或 instance id？
• SDK 如何支持灰度、远程开关、禁用某个采集插件？
• SDK 版本升级后，旧业务的埋点配置如何兼容？

场景推演题

一个 React 主应用里嵌了 Vue 子应用，两边都接入监控 SDK。用户点击子应用里的“提交审批”。如何避免重复采集，同时补齐主应用的用户、租户、路由上下文？

继续追：如果业务方要新增一个“富文本编辑器操作采集插件”，需要实现哪些接口？

准备证据

• SDK 初始化流程图。
• 插件接口伪代码。
• 声明式埋点事件 payload 样例。
• 多实例去重策略。

容易露馅的回答

• “封装一个 track 方法给业务调。”
• “框架适配就是导出几个 hook。”
• “插件报错 try/catch 一下就行，不用生命周期。”
• “微前端重复上报后端去重。”