识别嵌套函数变量遮蔽需从代码结构、命名习惯和工具提示三方面主动发现：检查内层同名let/const/var声明是否覆盖外层作用域；关注参数与外层变量同名情况；观察读写行为异常；借助ESLint no-shadow等工具即时预警；警惕window.xxx等全局访问补救写法。
识别嵌套函数中的变量遮蔽，关键不是等出 bug 再排查，而是从代码结构、命名习惯和工具提示三方面主动发现隐患。
看变量声明位置与作用域层级是否重叠
当内层函数（包括块级作用域、回调、箭头函数）中出现和外层同名的 let/const/var 声明时，就构成遮蔽。注意：即使没用 var，let 和 const 在块中重新声明外层变量，也会遮蔽——只是不会像 var 那样提升。
- 比如外层函数有
const userId = "U123"，内层 if 块里又写const userId = response.id，此时块内所有userId都指新值，外层原始值被“盖住”了 - 函数参数名和外层变量同名也属于遮蔽（如外层有
let status = "idle"，函数定义为function update(status) { ... }）
观察读写行为是否与预期不符
遮蔽最常暴露在运行时逻辑偏差中：
- 本想修改或读取外层状态，结果操作的是局部副本，导致外层值始终不变（例如计数器不累加、开关状态未更新）
- 嵌套函数多次调用后，输出值看似“随机变化”，实则是每次都在操作不同作用域下的同名变量
- 调试时在内层打日志看到的值，和外层同名变量的值完全不一致，但代码里又没显式赋值过去
依赖静态检查工具即时标出问题
人工肉眼容易忽略，必须靠工具提前拦截：
- JavaScript 项目启用 ESLint 的
no-shadow规则，它会直接报错：“'xxx' is already declared in the upper scope” - TypeScript 推荐用
@typescript-eslint/no-shadow，对类型上下文更敏感 - Java 中 IDE（如 IntelliJ）默认高亮被遮蔽的字段，鼠标悬停会提示 “Shadows field from outer class”
- Go 编辑器（如 VS Code + gopls）会对短变量声明
:=遮蔽包级变量给出警告
检查是否误用了全局访问方式
有些开发者意识到遮蔽后，会用 window.xxx（浏览器）或 global.xxx（Node.js）强行绕过，这本身就是信号：
- 代码里突然出现
window.userToken，但其他地方都用userToken，说明局部变量可能把全局的盖住了 - Java 中频繁出现
OuterClass.this.field，往往意味着内部类或方法参数引发了遮蔽 - 这类写法不是错误，但它是“我们已经发现了遮蔽并正在补救”的明确痕迹
