全局执行上下文污染本质是变量意外挂载到window或globalThis，导致命名冲突等；应通过快照比对、定向清除、防御加固三步安全清理，并以严格模式、显式声明、模块化等习惯预防。
全局执行上下文被污染，本质是意外将变量挂到了 window（浏览器）或 globalThis（跨环境）上，导致命名冲突、内存泄漏或难以调试的行为。清理不是“删掉所有”，而是识别、隔离、移除非必要暴露的变量。
识别哪些变量属于污染
污染变量通常具备以下特征：
- 未声明直接赋值，例如
userName = "admin"（缺少let/const/var） - 函数内使用
this指向全局对象并动态添加属性，如this.tempFlag = true - 第三方脚本或老旧代码显式写入
window.xxx = ...，但未提供清理机制 - 模块未正确封装，通过 IIFE 或导出方式失控暴露内部变量
安全清理的实操步骤
不要在生产环境随意遍历删除 window 属性——可能误伤框架或库依赖的合法全局变量。推荐分三步操作：
-
快照比对：页面加载完成时记录初始全局属性名集合（
Object.getOwnPropertyNames(window)），后续排查新增项即为可疑污染 -
定向清除：确认某变量确属临时/调试/废弃用途（如
debugData、tempResult），用delete window.varName移除（注意：var声明的变量不可删，let/const不会挂全局） -
防御加固：在入口脚本顶部启用严格模式（
"use strict"），让未声明赋值直接报错，从源头阻断隐式全局
避免污染的长期习惯
清理是补救，预防才是关键：
- 所有变量显式声明，禁用
with和eval（它们极易扩大作用域） - 用模块化（ESM）替代 script 拼接，天然隔离顶层作用域
- 调试时优先用
console.table()或闭包临时变量，而非挂window - 第三方 SDK 加载后，查阅文档确认其是否注入全局变量；必要时用沙箱 iframe 或
Proxy代理window限制写入
污染变量不是 bug，是信号——提示代码组织或执行环境存在松散边界。每次清理，都该同步回溯产生原因。
