不推荐使用var声明全局变量，因其变量提升、函数作用域及隐式挂载window等特性易引发作用域混乱；应优先用let/const、es模块导出导入或严格模式规避风险。
在现代 JavaScript 中，不推荐使用 var 声明全局变量，更不应主动用它制造全局污染或“解决”作用域冲突。它的变量提升（hoisting）、函数作用域、以及在非严格模式下意外挂载到全局对象（如 window）等特性，恰恰是引发作用域混乱和难以调试问题的根源。
var 声明全局变量的实际行为（不等于“有意声明全局”）
var 本身没有“全局声明语法”，它只遵循作用域规则：
- 在**函数外部**直接用
var x = 1，变量会成为全局对象的属性（如浏览器中window.x），这是全局变量； - 在**函数内部**用
var y = 2，变量仅在该函数内有效（函数作用域），不会污染全局； - 但若在函数内**漏写
var**（如直接写z = 3），则无论在哪，都会隐式创建全局变量——这才是常见冲突源头。
var 引发作用域冲突的典型场景
以下代码看似无害，实则危险：
function foo() {
var a = 10;
if (true) {
var a = 20; // 不报错！var 允许重复声明，且提升到函数顶部
console.log(a); // 20
}
console.log(a); // 20 —— 并非预期的 10，因 var 没有块级作用域
}
这种行为容易覆盖同名变量，尤其在大型项目或多人协作中，导致逻辑错乱。
正确替代方案：用 let/const + 明确作用域设计
解决“想全局”或“怕冲突”的真实需求，应转向现代语法和工程实践：
-
需要真正全局共享？显式挂载到
window或globalThis（跨环境安全），并加命名空间前缀，例如：globalThis.MY_APP_CONFIG = { apiBase: '/api' }; -
模块间共享数据？用 ES 模块导出/导入：
// config.js<br>export const API_URL = 'https://api.example.com';<br>// main.js<br>import { API_URL } from './config.js'; -
避免意外全局？始终启用严格模式（
'use strict';），此时漏写let/const/var会直接报错，杜绝隐式全局。
如果必须兼容旧代码，如何最小化 var 风险？
仅限维护遗留系统时参考：
- 所有
var声明统一放在函数/脚本**顶部**，避免条件分支中重复声明； - 全局变量统一用大写常量名（如
GLOBAL_TIMEOUT_MS）并加注释说明用途； - 用工具检查：ESLint 规则
no-var和no-implicit-globals可自动拦截问题写法。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
