ReferenceError 是暂时性死区（TDZ）最直接的信号，即在 let/const 声明前访问变量会立即抛出该错误，表明变量已绑定但未初始化；TDZ 存在于块顶部到声明执行完成之间，影响 typeof、默认参数、解构等隐式求值场景。
ReferenceError 是暂时性死区最直接的信号
当你在 let 或 const 声明语句之前访问该变量，JavaScript 会立刻抛出 ReferenceError: xxx is not defined——注意，这不是语法错误（SyntaxError），也不是 undefined，而是运行时明确拒绝访问。这说明变量已被“绑定”进当前作用域，但尚未初始化。
- 哪怕只是
typeof x，也会报错；而var下同操作返回"undefined" - 死区从块（如
{}、if、for、函数体）顶部开始，到let x或const y = ...这一行执行完成为止 - 嵌套块中，每个
let/const都有独立 TDZ，外层同名变量不影响内层判断
let 和 const 都受 TDZ 约束，但 const 多一层限制
let 和 const 都存在暂时性死区，因为它们都经历“声明提升 + 未初始化”的过程；区别在于：const 还强制要求声明时必须赋值，否则直接 SyntaxError。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
let a;合法，但a在声明前不可读写 -
const b;语法错误，根本过不了解析阶段 -
const obj = {};允许后续修改obj.prop = 1，但不能obj = {}—— TDZ 管的是“绑定”，不是“值不可变”
常见踩坑场景：看似安全的操作其实危险
很多开发者以为 typeof、函数默认参数、对象解构默认值是“兜底操作”，但在 TDZ 下全都不起作用。
-
console.log(typeof tmp); let tmp = 123;→ 报错，不是"undefined" -
function foo(x = tmp) { let tmp = 'ok'; }→ 调用foo()时立即报错，因为默认参数求值发生在函数体执行前，而此时tmp仍在 TDZ 中 -
let {x = 1} = {y: 2};合法，但若x是外部let x且尚未声明，则解构表达式本身会触发 TDZ 错误
怎么避免 TDZ 问题？靠习惯，不靠运气
ESLint 的 no-use-before-define（开启 variables: true）能捕获大部分情况，但最可靠的方式是建立编码习惯：
- 把所有
let/const声明统一放在块的开头（不是强制，但显著降低出错概率） - 避免在声明前做任何求值行为：包括调用函数、访问对象属性、计算表达式、甚至
void 0这类看似无害的操作 - 在条件块或循环中声明变量时，确认逻辑路径不会绕过声明语句（比如
if (false) { let x = 1; }后面直接用x就掉进死区）
import 中的命名绑定，它们同样遵循 TDZ 规则，但不像 console.log(x) 那样一目了然。 
