很多人知道 let 和 const 有块级作用域，却容易忽略它们还带着一条更严格的运行时规则：在声明真正执行之前，变量虽然“名字已经存在于当前作用域”，但依然不能访问。这段区间就是暂时性死区，也就是 TDZ。
这类问题最常见的表现，就是代码看起来只是“提前读了一下变量”，结果运行时直接抛出 ReferenceError。下面按触发范围、典型报错、实际价值和排查方法四个部分梳理，帮助你判断什么时候是正常限制，什么时候该调整声明顺序。
TDZ 是怎么触发的，范围又到哪里
在 JavaScript 中，块级作用域里使用 let 或 const 声明变量时，会触发“暂时性死区”（Temporal Dead Zone，TDZ）机制。它指的是：从当前块开始，到变量声明语句执行之前，这个变量都不可访问；一旦访问，就会抛出 ReferenceError。
这不是语法层面的报错，而是运行时限制。也就是说，代码可以通过解析，但在真正执行到相关位置时失败。需要注意的是，TDZ 只对 let 和 const 生效，var 不受这套规则影响。
- 即使变量声明写在块内部较后的位置，TDZ 也会从块顶部就开始生效。
- 它影响的不只是取值，赋值、条件判断，甚至
typeof都可能触发错误。 - TDZ 不只出现在普通代码块里，函数参数作用域同样存在，尤其是默认参数场景。
一个容易误判的点是 typeof。很多人习惯把它当成“安全探测变量是否存在”的方法，但这个规则只适用于未声明变量；如果变量已经处在当前作用域、却仍落在 TDZ 中，那么 typeof 一样会报错，而不是返回 "undefined"。
哪些写法最容易踩进 TDZ
最典型的场景，就是在 let 或 const 声明前直接使用变量：
{
console.log(a); // ReferenceError: Cannot access 'a' before initialization
let a = 1;
}这里的问题不在于变量没有定义，而在于它已经进入当前块级作用域，但初始化尚未完成，所以引擎明确禁止访问。
实际开发里，常见踩坑方式通常有下面几类：
- 在
let/const声明之前读取变量，例如console.log、比较表达式、模板字符串拼接等。 - 在声明前对变量赋值或参与计算，例如
x = 2、x + 1。 - 误以为
typeof能绕过限制，实际上对 TDZ 中变量依旧会抛ReferenceError。
函数默认参数也是 TDZ 的高发区。比如下面这种前项依赖后项的写法：
function fn(x = y, y) { }调用 fn() 时会报错。原因是参数初始化本身就形成了独立作用域，x = y 执行时，后面的 y 还没有完成初始化，因此落入 TDZ。
循环里也容易出现类似问题。原文里的这段代码：
for (let i = 0; i < 5; i++) { console.log(i); let i = 10; }它首先会因为重复声明而成为语法错误，不能直接作为 TDZ 示例来理解。但这类代码提醒了一件事：在循环体、分支块或嵌套作用域中，只要你引入了新的 let/const 绑定，同名或相关变量的可见性就可能和预期不同，稍不注意就会在“声明之前的那一段”触发 TDZ。
TDZ 不只是限制，也是在帮你约束代码
很多人第一次接触 TDZ 时，会把它当成一条“容易报错的麻烦规则”。但从语言设计角度看，它本质上是在阻止“先使用、后声明”这类可读性差、容易引发歧义的写法。
这条机制至少带来几个直接好处。
强制把声明顺序写清楚
有了 TDZ，变量生命周期会更明确。你必须先声明，再使用，代码阅读者也更容易沿着执行顺序理解逻辑，不需要猜“这个变量是不是靠提升在前面就能用”。
让块级作用域隔离更可靠
在 if、for 或普通 {} 代码块里，用 let 和 const 声明只在当前分支有效的变量，会比 var 更清晰。TDZ 进一步防止你在变量还没准备好时就提前读取，减少局部逻辑被意外串用的情况。
及时暴露初始化顺序问题
在模块配置、常量组合、对象初始化这类场景里，TDZ 其实很有价值。比如：
const config = { api: API_BASE, timeout: config.api ? 5000 : 3000 }这类代码会报错，恰好说明初始化顺序本身就有问题：config 还没完成创建，就试图在自身内部再次读取它。TDZ 在这里起到的是“尽早失败”的作用，逼着你把依赖关系拆清楚，而不是让隐式提升掩盖结构问题。
遇到 TDZ 报错，怎么快速定位
TDZ 的好处是报错特征通常很明显。只要看到这类信息：
ReferenceError: Cannot access 'xxx' before initialization基本就可以优先怀疑是不是在声明执行前访问了某个 let 或 const 变量。
排查时可以按下面几个方向看：
- 先确认报错变量在当前块、函数或参数列表中的声明位置，看看访问语句是否写在它前面。
- 用
console.log在相关代码附近打点，观察程序到底执行到了哪一行；如果某一行看似普通的访问直接中断，通常就是踩进了 TDZ。 - 检查默认参数、嵌套块作用域和同名变量遮蔽，这几个地方最容易让人误判变量来源。
- 在工程里启用 ESLint 规则
no-use-before-define，可以提前发现一部分潜在风险，对let/const同样有帮助。
如果你平时把这类报错简单归结为“变量没定义”，很容易漏掉真正原因。TDZ 更准确的判断方式是：变量属于当前作用域，但初始化尚未完成。
理解 TDZ 后，写法该怎么调整
实际编码时，最稳妥的原则很简单：把 let 和 const 的声明尽量放在第一次使用之前，涉及默认参数和初始化依赖时尤其要明确顺序。
如果一段代码总是因为 TDZ 出错，通常不只是“语法位置放错了”，更可能说明这段逻辑的依赖关系本来就不够清楚。顺着 TDZ 报错去重排声明、拆分初始化步骤，往往能把代码结构一起理顺。
