JavaScript 的数据类型并不算多，但它的坑特别密集。真正让人频繁踩坑的，不是“记不住有哪些类型”，而是 null 和 undefined 的语义差异、== 的隐式转换、类型判断手段的适用边界，以及字符串转数字时一不留神就出错的规则。
如果你最近正在补前端基础、排查线上 Bug、准备面试，这篇可以把最常用也最容易答错的四块知识一次串起来。
一、null 和 undefined 到底差在哪
很多人第一次学 JS 会觉得这两个值都表示“空”，所以差不多能互换。问题在于，JS 引擎和业务代码对它们的含义并不是同一种理解。
| 维度 | undefined | null |
|---|---|---|
| 语义 | 系统给出的默认缺省值 | 开发者主动表达的空值或空对象占位 |
| 来源 | 变量未赋值、函数无返回值、属性不存在、参数未传入 | 手动置空对象、DOM 查询失败、原型链终点 |
| typeof 结果 | undefined | object |
| 推荐理解 | 还没有值 | 有意设置为空 |
let a;
console.log(a); // undefined
function test() {}
console.log(test()); // undefined
const obj = {};
console.log(obj.name); // undefined
let user = { name: 'Tom' };
user = null;
console.log(typeof undefined); // 'undefined'
console.log(typeof null); // 'object'typeof null === 'object' 并不是“null 属于对象”，而是 JavaScript 早期实现遗留下来的兼容行为。它是历史 Bug，但已经无法移除。
工程建议：如果你是在表达“这个变量还没拿到值”，保留 undefined 更自然；如果你是在表达“这里原本应该有对象，但我现在主动清空”，用 null 更清晰。
二、为什么项目里几乎总是推荐用 ===
== 和 === 的差别，不是“一个宽松一点，一个严格一点”这么简单。真正关键的是：== 会先做隐式类型转换，再比较值；而 === 不做转换，类型和数值都要一致。
console.log(1 == '1'); // true
console.log(0 == false); // true
console.log('' == false); // true
console.log(null == undefined); // true
console.log(1 === '1'); // false
console.log(0 === false); // false
console.log(null === undefined); // false
console.log(NaN === NaN); // false之所以团队规范更偏向 ===，不是因为它“更高级”，而是因为它更可预测。你在代码评审里看到一行 ===，几乎不需要额外猜转换过程；但看到 ==，就必须先脑补 JS 会不会偷偷帮你转类型。
- 推荐默认规则：日常业务判断统一使用
===。 - 少数例外：如果你明确要把
null和undefined合并判空，value == null是有实际价值的写法。 - 必须记住：
NaN无论宽松还是严格比较，都不等于它自己。
三、JS 类型判断不能只靠一种方法
JavaScript 没有一种判断手段能覆盖所有类型并且在所有场景都无坑。最稳的做法，是先知道每种方式能解决什么问题，再按场景挑工具。
| 方式 | 适合判断什么 | 主要问题 |
|---|---|---|
| typeof | number、string、boolean、undefined、function | 无法区分 null、数组、普通对象 |
| instanceof | 数组、日期、正则、自定义实例对象 | 不适合基本类型，跨 iframe 场景可能失效 |
| constructor | 构造来源明确的对象 | 可被手动改写，不够稳 |
| Object.prototype.toString.call | 几乎所有内置类型 | 写法相对长，但最通用 |
console.log(typeof 123); // 'number'
console.log(typeof null); // 'object'
console.log([] instanceof Array); // true
console.log((123).constructor === Number); // true
console.log(Object.prototype.toString.call(null)); // [object Null]
console.log(Object.prototype.toString.call(undefined)); // [object Undefined]
console.log(Object.prototype.toString.call([])); // [object Array]
console.log(Object.prototype.toString.call({})); // [object Object]如果你只是做一个轻量判断，比如判断变量是不是字符串，typeof 就够了；但如果你在写工具函数、SDK 或通用业务逻辑，直接上 Object.prototype.toString.call 通常更稳。
四、字符串转数字为什么总会出边界 Bug
前端里最常见的类型转换之一，就是把表单输入、URL 参数、接口字段从字符串转成数字。难点在于，不同 API 的“容错方式”完全不同。
| 方式 | 规则 | 典型场景 |
|---|---|---|
| Number() | 要求整体是合法数字格式，否则返回 NaN | 严格转换、后端参数校验 |
| parseInt() | 从左到右提取整数，遇到非数字停止 | 从混合字符串提取整数 |
| parseFloat() | 与 parseInt 类似，但支持小数 | 从混合字符串提取浮点数 |
| +value | 本质上接近 Number() 的隐式转换 | 代码短、场景明确时使用 |
console.log(Number('123')); // 123
console.log(Number('123abc')); // NaN
console.log(Number('')); // 0
console.log(Number(null)); // 0
console.log(parseInt('123abc', 10)); // 123
console.log(parseInt('3.14', 10)); // 3
console.log(parseFloat('3.14abc')); // 3.14
console.log(+'123.45'); // 123.45
console.log(+'abc'); // NaN真正容易出错的不是“不会用”，而是把宽松提取和严格转换混在一起。例如订单金额这种字段，本来就应该使用 Number() 做严格转换；而像“20px”这类字符串提取数值，才更适合 parseInt()。
五、面试或项目里最值得背下来的结论
- null 与 undefined：一个是主动空值，一个是系统缺省值，语义不同，宽松相等但严格不等。
- == 与 ===：大多数业务代码统一使用
===，因为结果更可预测。 - 类型判断：简单场景用
typeof，复杂或通用场景用Object.prototype.toString.call。 - 字符串转数字：
Number()适合严格转换，parseInt()和parseFloat()更适合提取数值片段。
如果把这四块知识理解透，JavaScript 数据类型相关的多数基础题和真实项目坑点，基本就都落在你的掌控范围里了。
