应禁止将 undefined 用作局部变量名，因其会覆盖全局 undefined 导致类型判断失真、逻辑错误及调试困难，推荐使用 typeof x === 'undefined' 或 void 0 替代。
在函数作用域内用 undefined 作为局部变量名，看似无害，实则埋下隐蔽陷阱——它会覆盖该作用域中原本的全局 undefined 值，导致类型判断失真、逻辑误判甚至难以复现的 bug。
覆盖原始语义，破坏类型检测可靠性
JavaScript 中 undefined 的核心意义是“未初始化”或“不存在”，许多判断逻辑依赖它保持纯净。一旦在局部声明同名变量：
-
function foo() { let undefined = 'hacked'; console.log(typeof bar === 'undefined'); }—— 这里typeof bar === 'undefined'仍为true（因为typeof是操作符，不访问变量），但若改用bar === undefined，结果就变成false，逻辑断裂 - 第三方库或团队通用工具函数（如
isUndefined(val)）若内部直接比对val === undefined，在该函数体内就会失效
混淆调试与协作认知
开发者看到 undefined，本能认为它代表“JS 默认未赋值状态”。但局部重定义后：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
console.log(undefined)输出的是你赋的值（比如0或false），不是原始undefined - 新人阅读代码时无法区分哪一个是语言原生含义，哪一个是人为干扰项
- 静态分析工具（如 ESLint）可能报
no-shadow警告，但若被忽略，问题会潜伏到运行时
严格模式下也不安全
有人误以为 "use strict" 能阻止这种覆盖——其实不能：
- 严格模式禁止给全局
undefined赋值（undefined = 1报错），但允许在函数内let undefined = ...或var undefined = ... - ES6+ 中
let/const声明会创建块级绑定，此时undefined只在该块内被遮蔽，风险范围更隐蔽 - 真正安全的替代写法是
void 0（始终返回原始undefined）或显式用window.undefined（仅限浏览器环境）
实际建议：主动规避，统一约定
与其依赖“我只在自己函数里用，不会影响别人”，不如从源头杜绝：
- 禁用 ESLint 规则
no-shadow的builtinGlobals: true选项，让undefined、NaN、Infinity等内置标识符不可被遮蔽 - 判断是否未定义，优先使用
typeof x === 'undefined'（不受局部变量影响） - 需要显式表示“空值占位”时，用
void 0替代字面量undefined，语义清晰且绝对可靠 - 团队代码规范中明确禁止将
undefined用作变量名、参数名或解构别名
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
