JavaScript变量与数据类型需持续实践：var/let/const核心区别在作用域、提升和重复声明规则；原始类型7种，typeof和instanceof有局限；TDZ导致let/const块内提前访问报错；BigInt和Symbol各有使用边界；类型安全依赖工具而非死记。
JavaScript 的变量和数据类型不是“学完就一劳永逸”的知识，而是日常写代码时高频踩坑的源头。能不能正确声明、用对类型、避开隐式转换陷阱，直接决定你写的逻辑是否可靠。
var / let / const 到底该选哪个？
三者本质区别不在“能不能重新赋值”，而在**作用域、提升（hoisting）行为和重复声明规则**：
-
var会函数作用域提升，且允许重复声明 —— 容易导致意外覆盖或undefined访问 -
let和const是块级作用域，不提升（但存在“暂时性死区”），不允许重复声明 -
const不代表“值不可变”，只代表“绑定不可重赋”；对象/数组本身仍可修改属性或元素
实操建议：
- 默认用
const，除非明确需要重新赋值（比如循环计数器），再换let - 彻底弃用
var，尤其在函数外或嵌套块中，它带来的混乱远大于兼容性收益 - 声明即初始化，避免
const obj = {};后又反复obj.a = 1这类弱约束写法 —— 改用Object.freeze()或 TypeScript 类型约束更可靠
7 种原始类型 + Object，但 typeof 和 instanceof 经常撒谎
原始类型有：string、number、boolean、null、undefined、symbol、bigint；其余都是 object（包括 Array、Date、RegExp、Promise，甚至 null！）
这意味着：
-
typeof null === 'object'是历史 bug，至今未修复 -
typeof []、typeof new Date()、typeof /abc/全是'object'，无法区分 -
instanceof在跨 iframe 场景下失效（不同全局环境的Array构造函数不等价）
实操建议：
- 判断数组用
Array.isArray()，别信typeof或instanceof Array - 判断日期、正则等内置对象，优先用
Object.prototype.toString.call(x)，例如：Object.prototype.toString.call(new Date()) // '[object Date]'
- 检查
null必须显式写x === null，不能靠!x（因为undefined、0、''也假）
let 声明的变量为什么在块内访问会报 ReferenceError？
这不是 bug，是设计：let 和 const 存在“暂时性死区”（TDZ）。从块开始到声明语句执行前，变量处于不可访问状态。
常见错误现象：
console.log(a); // ReferenceError let a = 1;
- 在
for循环中误以为每次迭代都新建变量，实际是每次迭代绑定新值 —— 闭包里取i仍是最后一个值（需用let声明在循环体内才真正隔离）
实操建议：
- 声明尽量靠近首次使用位置，避免跨多行“悬空”声明
- 不要依赖 TDZ 报错来检测变量是否存在 —— 应该用
in操作符或hasOwnProperty查属性，用typeof x === 'undefined'查变量是否声明（仅限var） - 想实现“块级私有”，用
{ let x = ... }包裹，而不是靠注释或命名约定
BigInt 和 Symbol 容易被忽略的使用边界
BigInt 解决大整数精度丢失，但代价是不能和 number 混算；Symbol 保证唯一性，但不等于“私有”。
常见误区：
-
1n + 1直接报错，必须写成1n + 1n；Math.max(1n, 2n)也不行 ——BigInt不参与大多数内置数学函数 -
Symbol('foo') === Symbol('foo')是false，但Symbol.for('foo') === Symbol.for('foo')是true—— 后者注册到全局符号注册表，慎用 -
Symbol属性不会出现在for...in、Object.keys()中，但能被Object.getOwnPropertySymbols()和Reflect.ownKeys()拿到 —— 所谓“隐藏”只是遍历 API 的盲区
实操建议：
- 处理 ID、时间戳、加密哈希等可能超
Number.MAX_SAFE_INTEGER（9007199254740991）的整数时，才引入BigInt；日常计数、索引继续用number - 用
Symbol做对象属性名时，把 symbol 存在模块顶层常量里，避免散落各处造成维护困难 - 别指望
Symbol防止外部访问 —— 真要封装，用闭包或#privateField（ES2025 私有字段）
类型系统松散是 JavaScript 的特点，也是它的负担。真正难的不是记住 typeof null 返回什么，而是在读别人代码或调试异步链时，能一眼识别出某个 value 是 string 还是 number 还是 Promise —— 这时候，类型注解（JSDoc）、运行时校验（如 zod）、或者直接上 TypeScript，比死记规则管用得多。
