在阅读 JavaScript 源码,尤其是压缩后的代码时,很多人常常会遇到这样的片段:
scss
if (!0) { /* ... */ } // 等价于 if (true)
if (!1) { /* ... */ } // 等价于 if (false)
这些诡异的语法你可能一开始会觉得费解,但其实是压缩器(比如 UglifyJS、Terser)为了追求 最小体积和最高性能 的结果。
这一类代码就是所谓的 JavaScript 压缩写法。它们压缩得极致,同时也保持了逻辑一致性。下面我们就系统聊聊有哪些经典写法、为啥这么写、哪些能用哪些要注意。
🧱 布尔值压缩:true/false 最短写法
语义 | 原始写法 | 压缩写法 | 说明 |
---|---|---|---|
true | true |
!0 |
逻辑真 |
false | false |
!1 |
逻辑假 |
强制转布尔值 | Boolean(x) |
!!x |
常见强转布尔写法 |
!!x
是最经典的布尔转型写法,用得非常广泛,比如:
ini
const isValid = !!user.id;
🧪 undefined 与 null 的压缩技巧
意图 | 原始写法 | 压缩写法 | 说明 |
---|---|---|---|
undefined 值 | undefined |
void 0 |
永远返回 undefined |
判断 undefined 类型 | typeof x === 'undefined' |
typeof x == 'undefined' |
双等号足够安全 |
判断是否为 null | x === null |
null == x |
包括 null 和 undefined |
void 0
是一个冷门但安全的写法,它绕过了 undefined
可能被覆盖的问题(老浏览器或者手动重写)。
🔁 条件逻辑压缩
原始写法 | 压缩写法 | 含义 |
---|---|---|
x ? true : false |
!!x |
转换为布尔值 |
x ? x : y |
`x | |
x ? y : null |
x && y |
x 存在则执行 y |
if (x) return true; |
return !!x; |
简洁返回布尔 |
这些写法多数来自于逻辑短路的使用,既压缩代码,也提升性能(少一层判断)。
🔎 类型判断 & 替代操作符
原始写法 | 压缩写法 | 说明 |
---|---|---|
typeof foo === 'function' |
typeof foo == 'function' |
双等号更短 |
Array.isArray(x) |
x instanceof Array |
兼容性略差,但更短 |
x !== undefined |
void 0 !== x |
避免使用 undefined 字面量 |
压缩器通常偏好双等号 ,因为其字节更少。而 typeof
场景下使用双等号其实是安全的(因为不会触发类型转换)。
📦 数组与对象压缩
原始写法 | 压缩写法 | 说明 |
---|---|---|
[1, 2, 3].length |
3 |
直接写字面量节省字符 |
{a: a} |
{a} |
ES6 对象属性简写 |
obj['key'] |
obj.key |
如果 key 合法,更短更直观 |
这些优化大多自动由现代压缩器处理,无需人工介入,但有助于理解源码。
📉 函数和箭头函数优化
原始写法 | 压缩写法 | 说明 |
---|---|---|
function () {} |
()=>{} |
箭头函数更短 |
function(a){ return a*2 } |
a=>2*a |
单表达式更可简写 |
注意,箭头函数没有 this
,不要盲目替换类方法等。
🧮 数学与位运算优化
原始写法 | 压缩写法 | 说明 |
---|---|---|
Math.floor(x) |
~~x |
双按位取反等价于 floor |
Math.pow(x, 2) |
x * x |
常数次方直接展开更快更短 |
parseInt(x, 10) |
`+x | 0` |
但这些写法不要轻易使用在业务代码中 ,因为会让代码可读性大幅下降。
🎲 Bonus:冷门但实用的压缩技巧
原始写法 | 压缩写法 | 说明 |
---|---|---|
for (let i=0; i<n; i++) |
for(i=n;i--;) |
倒序遍历节省初始化代码 |
a != null |
null != a |
可以避免 null 和 undefined |
x && x.fn() |
x?.fn() |
可选链更短,但需现代浏览器支持 |
✅ 写在最后:压缩写法是"写给机器的代码"
这些技巧大多来源于压缩器的优化逻辑,是写给机器看的代码。
开发者日常业务中,并不推荐自己手动这么写。更推荐的是:
- 业务代码保持可读性
- 构建阶段交给打包工具压缩
- 理解这些写法,能更好阅读源码、调试、做逆向