全局变量污染命名空间的典型表现是多脚本中未隔离地定义var/let/config导致值被意外覆盖，且window.userId等可直接访问；应优先用export/import，必要时通过constants.js、封装函数或class管理共享状态，避免var在非函数作用域声明，并谨慎处理第三方库的全局挂载。
全局变量污染命名空间的典型表现
当你在多个脚本中都定义了 var userId 或 let config，又没做模块隔离，后续某个脚本意外覆盖了前一个值，调试时很难定位——错误往往出现在完全不相关的代码行。浏览器控制台里 window.userId 能直接访问，说明它已挂载到全局对象上，任何地方都能读写。
模块作用域下如何安全暴露变量
现代项目应优先用 export / import 显式声明依赖，而不是靠全局变量“碰运气”。如果必须跨模块共享，推荐：
- 用
const API_BASE_URL = 'https://api.example.com'定义在单独的constants.js中，再import使用 - 封装成函数返回值，比如
getAuthHeader()，避免裸露原始 token 字符串 - 若需动态状态，用
class实例管理，而非把实例直接赋给window.appState
var 声明在函数外等于全局变量
很多人以为只在最外层写 let 或 const 才危险，其实 var 在任何非函数作用域中声明（包括 if 块、for 循环内），只要不在函数里，都会提升到全局作用域。例如：
if (true) {
var globalLeak = 'oops';
}
console.log(window.globalLeak); // 'oops'
而 let 和 const 在块级作用域外访问会直接报 ReferenceError，这是更安全的默认行为。
立即学习“Java免费学习笔记（深入）”；
第三方库加载时悄悄创建全局变量
有些老库（如 jQuery 1.x、underscore）默认把主对象挂到 window.$ 或 window._。如果你用的是打包工具（Webpack/Vite），可以通过配置 externals 或使用 import $ from 'jquery' 来避免；纯 script 标签引入时，建议立即用 IIFE 封装使用逻辑，防止后续脚本意外依赖这些全局符号。
真正难处理的是那些既没提供 ES 模块导出、又没声明 umd 兼容格式的脚本——它们强迫你接受全局变量，这时候得手动加一层包装，比如用 const myLib = window.MyLib 然后立刻删掉 window.MyLib，至少让污染可控。
