let声明变量报“identifier 'xxx'已声明”是因块级作用域绑定+编译期静态检查+暂时性死区协同作用：引擎在解析阶段即注册标识符，同一块内重复let声明直接抛syntaxerror，且控制台不自动清除绑定。
控制台里用 let 声明变量报“Identifier 'xxx' has already been declared”，不是浏览器故意为难你，而是 JavaScript 引擎严格按规范执行的结果——核心在于 块级作用域绑定 + 编译期静态检查 + 暂时性死区（TDZ）机制 的协同作用。
let 变量在编译阶段就完成作用域绑定
V8 等现代引擎在代码执行前会先进行编译（Parsing & Hoisting 阶段）。此时：
- var 只绑定到函数或全局作用域顶部，且允许重复声明（语法上不报错）；
-
let 则会在当前块级作用域（比如控制台的一次输入、一个
{}、或 IIFE 内部）中，为每个标识符创建唯一绑定； - 这个绑定一旦建立，引擎就记住了“这个名字在此块内已被声明”，后续再遇到同名
let x，直接在编译阶段抛出SyntaxError，不进入执行阶段。
控制台每次执行是独立的“顶层块”，但状态持续存在
Chrome DevTools 控制台默认把每条语句当作顶层块级作用域的一部分（类似模块顶层），而且不会自动清空已声明的 let/const 绑定：
- 第一次输
let a = 1→ 引擎在当前块中注册a； - 第二次再输
let a = 2→ 同一作用域内尝试二次注册，触发静态检查失败； - 注意：清除控制台日志（Clear console）不会销毁已声明的变量绑定，必须刷新页面或关闭标签页才能重置作用域环境。
暂时性死区强化了“一次声明”语义
TDZ 不只是“不能提前访问”，它本质是语言设计上对“声明即注册”的强制体现：
- 从块开始到
let x语句执行前，x已存在但不可访问； - 这种“已存在但受限”的状态，意味着引擎必须在块入口就预留该标识符的位置；
- 如果允许重复声明，就会破坏 TDZ 的一致性——同一个名字在块内可能对应多个不同生命周期的绑定，逻辑无法自洽。
为什么 var 不报错？对比更清楚
var 的行为源自 ES5 时代的设计妥协：
- 它只做“函数作用域提升”，不记录声明次数，重复
var x被视为同一变量的多次赋值准备； - 引擎不检查重声明，甚至允许
var x; var x = 1;这样的写法； - 而
let是 ES6 明确引入的“严格声明机制”，目标就是消除var的歧义和隐患，所以编译期拦截是必然选择。
