应优先避免全局变量,若必须使用,须用const/let声明、封装命名空间、采用模块化导出,并禁用var和隐式全局。

在全局作用域中声明变量,核心原则是“能不声明就不声明”,但若必须使用,需兼顾可读性、安全性与可维护性。现代 JavaScript 已不再鼓励随意挂载全局变量,而是通过明确的声明方式、作用域隔离和模块化思路来约束它。
优先用 const/let 替代 var 声明
即使在全局作用域,也应避免使用 var。它会带来变量提升、重复声明允许、无块级作用域等问题,容易引发隐蔽错误。
- const:用于值不会重新赋值的全局配置或常量(如 API 地址、版本号)
- let:仅当确实需要后续修改时才用(如全局计数器、状态标记)
- 不写 var,也不省略关键字(如直接写
userName = "Tom"会意外挂到window上,极危险)
限制全局变量的数量和命名空间
把多个相关变量组织在一个顶层对象里,相当于手动创建命名空间,避免污染全局环境。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如:
const AppConfig = { apiUrl: "/api", timeout: 5000 }; - 再比如:
const UserState = { isLoggedIn: false, profile: null }; - 这样既清晰又便于后续迁移到模块系统(如改用 ES Module 导出)
用模块化替代全局变量(推荐路径)
真正规范的做法,是根本不用全局变量——把逻辑拆进模块,按需导入导出。
- ES Module 中,
export const theme = "dark";和import { theme } from "./config.js";更安全可控 - 即使在非模块环境(如老项目 script 标签引入),也可用 IIFE 封装,只暴露必要接口
- 框架项目(React/Vue)中,全局状态应交由专门的状态管理工具(如 Redux、Pinia)处理,而非手写全局变量
必要时检查和清理全局污染
调试或迁移旧代码时,可主动检测意外挂载的全局变量:
- 浏览器中运行
Object.keys(window).filter(key => !/^(?:document|location|navigator|console|fetch)$/.test(key))查看非标准全局属性 - 构建工具(如 Webpack/Vite)开启
no-unused-vars或no-implicit-globals规则,提前拦截问题 - 团队协作中,在 ESLint 配置里启用
no-var和no-implicit-globals插件
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










