面试防线：声明式埋点如何处理动态渲染元素的事件绑定
面试官提问：
“你用全局事件委托来做声明式埋点，思路很好。但在现代 React/Vue 框架中，组件是极其频繁地销毁和重建的，而且还有无尽的异步渲染。你把事件挂在 document 上，怎么保证动态加载出来的按钮也能被准确捕获？会不会因为频繁绑定导致内存泄漏？”
核心回答思路 (STAR法则)
-
业务痛点 (Situation)
如果我们在每个组件的componentDidMount里去addEventListener，那么随着 React 重新渲染，必然会导致严重的事件绑定丢失或者重复绑定的内存泄露，这是传统侵入式埋点常犯的致命错误。 -
技术考量 (Task)
我们采用的**全局事件委托（Event Delegation）**的精髓，正是为了从根源上无视内部 DOM 的动态变化。必须讲清楚事件委托为什么天然对 React 动态渲染免疫，以及我们是如何沿着事件冒泡路径挖掘埋点数据的。 -
架构决策 (Action)
- 免疫组件销毁的全局委托：SDK 在全局只会在初始化时执行唯一一次
document.addEventListener(click, handler, true)。因为事件绑定在最外层的固定容器上，无论内部 React/Vue 怎么疯狂 diff 甚至销毁重建节点，只要用户的点击行为发生，浏览器原生事件冒泡/捕获机制就一定会把事件沿着当时的 DOM 树向上传递。因此根本不存在动态元素“绑定丢失”或“内存泄漏”的问题。 - 冒泡路径解析 (Event.composedPath)：核心挑战其实在于，当点击内层
<svg>或<span>时，真正的data-track可能写在外层的<button>上。我在 handler 中获取了原生的event.composedPath()（或者手工while(node.parentElement)向上遍历）。SDK 会沿着点击的确切物理路径向上扫描，直到找到带有data-track属性的节点为止，保证无论点击在按钮的哪个深层盲区，都能精准归因。 - 防范 React 阻止冒泡：因为 React 有合成事件系统，如果业务代码用了
e.stopPropagation()阻止了 React 内部的冒泡，挂在 document 冒泡阶段的原生监听器就可能收不到。因此我刻意将原生监听器挂载在捕获阶段 (Capture Phase, 传了 true)，它比任何 React 业务逻辑都先触发，做到了绝对的“上帝视角”拦截。
- 业务价值 (Result)
依靠这套纯正利用浏览器底层原生事件流机制的设计，我们的 SDK 完美适配了公司内部无论是老旧的 jQuery 项目，还是最前沿的 React 18 Suspense 项目，成为了一套真正的框架无关（Framework Agnostic）高可靠基础设施。