脚本作用域污染本质是不同脚本块因声明方式、执行时机或注入方式不当导致变量/函数意外覆盖、泄漏或不可见；修复核心在于明确每个script块的边界与生命周期。
脚本作用域污染不是“变量多了”，而是不同脚本块之间因声明方式、执行时机或注入方式不当，导致变量/函数意外覆盖、泄漏或不可见——修复核心是明确每个 script 块的边界和生命周期。
为什么内联脚本和外部脚本的作用域表现不一致
浏览器对每个 <script> 标签单独做作用域处理：内联脚本（<script>var a = 1</script>）和外部脚本（<script src="a.js"></script>）彼此不共享变量，哪怕写在同一 HTML 文件里。但 var 声明会被提升到当前块顶部，let/const 则受暂时性死区（TDZ）约束，跨块访问直接报 ReferenceError: x is not defined。
-
function foo() {}声明可跨块调用（提升生效），但若它内部依赖尚未解析的 DOM 节点，运行时仍会出错 -
const bar = () => {}不提升，前一个<script>块里定义了，后一个块里直接bar()就会报错 - 动态插入的
script（如document.createElement('script')）默认行为 ≈async，执行顺序不可控，极易打破预期作用域链
innerHTML 注入 script 标签为何不执行且污染全局
把含 <script>console.log(1)</script> 的字符串塞进 el.innerHTML，这段脚本既不会执行，也不会进入当前作用域——它被当成纯文本插入，之后若被浏览器重新解析（比如在某些旧版 IE 或特殊 context 下），才可能触发执行，且一定在全局作用域中运行。
- 所有内联
<style>和<script>都会逃逸到 document 级别，造成样式/变量污染 - 想安全执行动态代码，必须显式调用
eval()或new Function()，但这两者都绕过 CSP，且无法访问闭包变量 - 真正安全的做法是：用
DOMParser解析 HTML 字符串 → 提取<script>内容 → 在沙箱上下文（如iframe.contentWindow或 Shadow DOM 中的window）中执行
Shadow DOM 中如何避免脚本作用域穿透
attachShadow({ mode: 'open' }) 创建的 shadowRoot 是独立作用域边界，但这个边界只对 CSS 选择器天然生效；JS 作用域隔离需额外控制——shadowRoot.innerHTML = htmlString 是高危操作，因为其中的 <script> 仍在全局上下文中执行。
立即学习“前端免费学习笔记（深入）”；
- 不能直接在 shadowRoot 上调用
innerHTML注入带<script>的 HTML - 正确做法：提取 script 内容 → 创建
blob://URL → 动态创建<script src="...">并 append 到 shadowRoot，确保执行上下文绑定到当前 shadow - 第三方库（如 moment.js）若挂载到
window，会污染主文档；应在沙箱 iframe 或with (new Proxy({}, {...}))之类机制中加载 -
mode: 'closed'对 JS 隔离无增益，反而阻断调试和自动化测试，生产环境一律用mode: 'open'
作用域污染最隐蔽的点不在变量命名，而在执行时机与上下文绑定——比如一个 document.addEventListener('DOMContentLoaded', ...) 放在 <head> 里，它确实能等 DOM 就绪，但它注册的回调函数仍运行在全局作用域，闭包捕获的变量依然可能被后续脚本覆盖。真正的隔离需要结构级控制，而非仅靠命名或包裹。
