本文介绍如何使用 ESLint 的 no-shadow 规则检测子作用域中重复声明父作用域同名变量的问题，避免因变量遮蔽导致的逻辑混淆与调试困难。
本文介绍如何使用 eslint 的 `no-shadow` 规则检测子作用域中重复声明父作用域同名变量的问题，避免因变量遮蔽导致的逻辑混淆与调试困难。
在 JavaScript 中，当一个变量在内层作用域（如块级作用域、函数作用域或箭头函数）中使用与外层作用域相同的名称重新声明时，就会发生 变量遮蔽（variable shadowing）。这种写法虽合法（尤其在 let/const 块级作用域下），但极易引发理解偏差和潜在 bug —— 开发者可能误以为操作的是外层变量，实则修改或读取的是局部副本。
例如以下代码看似无害，却存在隐蔽风险：
{
const myVar = "ok";
if (true) {
const myVar = "not ok"; // ⚠️ 警告：遮蔽了外层 myVar
console.log(myVar); // 输出 "not ok"
}
console.log(myVar); // 输出 "ok" —— 外层值未被影响
}此时，no-redeclare 规则无法捕获该问题，因为它仅检查同一作用域内重复声明（如两次 const myVar 在同一块中），而遮蔽发生在不同嵌套层级的作用域之间。
✅ 正确的解决方案是启用 ESLint 的 no-shadow 规则：
// .eslintrc.json
{
"rules": {
"no-shadow": "error"
}
}该规则默认对所有声明类型（var、let、const、函数声明、类声明、参数等）生效，并严格检查嵌套作用域中的命名冲突。启用后，上述示例将触发清晰报错：
2:11 - 'myVar' is already declared in the upper scope. (no-shadow)
? 注意事项与最佳实践：
- no-shadow 默认不检查函数参数遮蔽全局变量（如 window 属性），如需更严格校验，可配合 "builtinGlobals": true 选项；
- 若需允许特定场景下的遮蔽（如 React 函数组件中解构 props 与 state 同名），可通过 /* eslint-disable no-shadow */ 在局部禁用，但应辅以注释说明理由；
- 对于 TypeScript 项目，@typescript-eslint/no-shadow 提供更精准的类型感知支持，推荐替代原生规则；
- 遮蔽本身不是语法错误，但高一致性团队规范中应视其为可维护性反模式——优先通过语义化命名（如 myVarInitial / myVarUpdated）消除歧义。
总之，no-shadow 是保障作用域清晰性的重要静态检查工具。将其纳入 CI 流程并配合编辑器实时提示，可显著降低因命名冲突引发的认知负荷与运行时意外。
