想要高效定位重复广告位的根本来源，直接打开 Network 面板，重点关注 Initiator 这一列。它会完整展示触发每个请求的 JavaScript 调用栈。不必陷入复杂思路，问题的本质并非“谁发起了资源请求”，而是“谁在反复向 DOM 注入内容”。因为资源重试本身不会造成节点重复，真正幕后黑手是插入逻辑被错误地多次执行。
如何精准定位重复插入广告的那段 JS
操作方法非常直观：启动 Chrome DevTools 的 Network 面板，勾选「Preserve log」防止刷新后记录丢失，随后正常刷新页面。找到那个出现两次的广告 iframe 请求，点击进入，在右侧 Headers 标签页向下滚动，定位到 Initiator 字段，单击它会自动跳转到对应的 JS 行。如果 Initiator 列显示的是 eval 或一串压缩后的匿名函数，不必慌张，向上翻看调用栈，寻找最靠近顶层且你能识别的函数名，例如 injectAd 或 renderBanner。排查范围不要只局限于第三方脚本，务必检查自己的代码：是否在 DOMContentLoaded 和 window.onload 中都调用了同一个插入函数？这种双保险机制往往正是灾难的源头。
innerHTML += 引起的广告 iframe 被反复追加
innerHTML += 虽然写法简洁，却是 DOM 重复插入的高发区。每次执行时，它会先将当前容器内的 HTML 字符串完整读取，拼上新内容，然后整体替换原有结构。这个过程会销毁已有节点、清空已绑定的事件，迫使浏览器重新解析整个 HTML——副作用极大。更隐蔽的是，如果第三方 SDK 内部也采用了类似逻辑，而你又在初始化时手动调用了一次，等于双重触发。替代方案很明确：使用 document.createElement('iframe') 配合 appendChild()，或者直接封装成“只插入一次”的幂等逻辑，比如在插入时给节点增加一个 data-injected="true" 标记并提前判断。此外，insertAdjacentHTML('beforeend', ...) 虽然比 innerHTML += 安全一些，不会重建整个容器结构，但依然无法解决重复执行的问题。
确认是否是 React/Vue 框架在“抢节点”导致二次渲染
如果页面上同时存在原生 JS 插入和前端框架接管的区域，框架的 diff 算法可能会把原生插入的节点识别为“脏节点”而直接覆盖或复制。这不是 bug，而是典型的 DOM 所有权冲突。排查时，先检查目标容器是否被框架的 root 或 el 配置覆盖，比如 new Vue({ el: '#container' }) 会让 Vue 完全接管整个节点及其子树。接着打开 Elements 面板，右键目标 iframe，选择 「Break on > subtree modifications」，刷新页面，观察断点停在哪段代码上。如果发现断点停在了框架内部方法（如 patch、hydrate），意味着框架在重写 DOM。此时应该改用框架提供的插槽（slot）或指令（如 v-html）来注入广告，而不是继续使用原生操作。临时验证方法也很有用：先注释掉框架初始化代码，仅保留原生插入逻辑，观察是否还会重复，能快速划分责任边界。
给广告 SDK 自动重试时加把“锁”，防止重复插入
许多第三方广告 SDK 在加载失败后会执行自动重试，但它们的插入函数往往没有做幂等保护。你无法修改 SDK 的代码，但可以在调用层做拦截。最简单的办法：使用闭包变量记录是否已插入，比如 let injected = false; if (!injected) { injectAd(); injected = true; }。更健壮的做法是检查 DOM 中是否已经存在对应广告节点：if (!document.querySelector('iframe[src*="ad-domain.com"]')) { injectAd(); }。需要注意的是，尽量避免用 id 来判断——第三方通常动态生成 ID，不可靠；优先使用 src 特征、data-ad-type 属性或固定的 class 名。时序因素也必须考虑：不要在 onload 回调里直接插入，应该在广告脚本 load 事件后、且确保 DOM 完全就绪后再执行插入。
真正麻烦的往往不是插入动作本身，而是插入时机和上下文混杂在一起：SDK 重试、框架接管、手动初始化、缓存失效后的 reload——这些信号只要没对齐，appendChild 就可能变成“appendTwice”。排查时不要只盯着那一行代码，而要关注每个插入动作背后的触发条件是否真正唯一。
