商品按价格排序,9 块钱排在了 80 块后面:我在 JavaScript 里被 Array.sort() 默认按字符串排序坑惨的那次线上事故

这个 bug 是产品经理截图发到群里、@我的时候,我才知道炸了。我做的一个商品列表页,有个"按价格从低到高排序"的功能。测试的时候没问题,上线后却收到一堆吐槽:排序完全是乱的。截图里,价格 9 元的商品,赫然排在了 80 元、100 元的后面;而 1000 元的,反而跑到了 200 元的前面。一个"从低到高"的排序,排出来的顺序,在用户眼里就是一团乱麻,毫无规律可言。

我当时一脸懵:排序逻辑我就用了个 array.sort(),这是 JavaScript 最基础的数组排序方法啊,能有什么错?我把数据拉出来,在控制台里一跑,结果让我倒吸一口凉气——一个普普通通的数字数组 [9, 80, 100, 1000, 200],调用 .sort() 之后,排出来的竟然是 [100, 1000, 200, 80, 9]!这顺序,既不是从大到小,也不是从小到大,看起来毫无逻辑。直到我盯着它看了半天,才猛然惊觉这个"乱序"背后那个荒谬的规律——JavaScript 的 Array.sort(),在你不给它指定比较规则时,默认竟然是把数组元素都转换成字符串,然后按字符串的字典顺序来排的!"100" 排在 "80" 前面,不是因为 100 < 80,而是因为字符串 "1" < "8"!

故障现场:一个数字数组,排出了字符串的顺序

我把这个荒谬的现象,在控制台里复现给你看:

// 一个普通的数字数组, sort() 一下:
const prices = [9, 80, 100, 1000, 200];
prices.sort();
console.log(prices);
// 你以为: [9, 80, 100, 200, 1000]  (从小到大)
// 实际是: [100, 1000, 200, 80, 9]  ← 毫无逻辑?!

// 为什么是这个顺序? 因为 sort() 默认把数字转成字符串, 按字典序比!
// 字符串比较是"逐个字符"比的:
//   "100"  vs  "80"   →  比第一个字符 '1' vs '8'  →  '1' < '8'  →  "100" 在前!
//   "1000" vs "200"   →  '1' vs '2'  →  '1' < '2'  →  "1000" 在前!
//   "80"   vs  "9"    →  '8' vs '9'  →  '8' < '9'  →  "80" 在前!
// 所以排出来: "100", "1000", "200", "80", "9"
//   → 这就是为什么 9 元排到了最后, 100 元跑到了最前!

// 更直观的经典例子:
console.log([1, 2, 10, 21, 100].sort());
// 不是 [1, 2, 10, 21, 100], 而是 [1, 10, 100, 2, 21] !
// 因为按字符串: "1" < "10" < "100" < "2" < "21"

看清这个规律时,我真是哭笑不得。我那个商品价格排序之所以乱成一团,根本原因是:Array.sort() 在我没有告诉它"该怎么比较"的情况下,擅自把每个价格数字,都转换成了字符串,然后按字符串的"字典顺序"去排——就像查字典、排英文单词那样,一个字符一个字符地比。于是,在字符串的世界里,"100" 因为第一个字符 '1' 小于 "80" 的第一个字符 '8',就被排到了前面;"9" 因为第一个字符 '9' 最大,反而被排到了最后。这个排序,从"数字大小"的角度看是彻底错乱的,但从"字符串字典序"的角度看,却又"完全正确"——它忠实地执行了它默认的、却完全不是我想要的那套规则。我那 9 块钱的商品排在 80 块后面,正是因为字符串 "9" > "8"。

第一件事:搞懂 sort() 默认的"字符串比较"规则

定位到现象,我必须搞懂这个反直觉的默认行为:为什么 sort() 要把数字转成字符串来排?查了 JavaScript 的规范,我把它彻底想透了。

// MDN/规范明确说: Array.prototype.sort() 如果【不传比较函数】,
//   会把所有元素【转换成字符串】, 再按字符串的 UTF-16 码元顺序排序。

// 规则: sort(compareFn?)
//   - 不传 compareFn: 元素转字符串, 按字典序排 (默认行为, 坑的来源!)
//   - 传 compareFn(a, b): 按你定义的规则排:
//       compareFn 返回 < 0: a 排在 b 前面
//       compareFn 返回 > 0: a 排在 b 后面
//       compareFn 返回 = 0: a 和 b 顺序不变

// 为什么默认要转字符串? 历史设计原因:
//   - sort() 要能给"任何类型"的数组排序(数字、字符串、对象...)
//   - 在不知道元素类型的情况下, "转成字符串再比" 是一个"通用的"默认策略
//   - 所以它选了这个"通用但常常不符合数字直觉"的默认行为

// 验证: 对字符串数组, 默认 sort() 是符合直觉的:
console.log(["banana", "apple", "cherry"].sort());  // ["apple","banana","cherry"] ✓
// 但对数字数组, 默认 sort() 就坑了:
console.log([9, 80, 100].sort());                   // [100, 80, 9] ✗ (按字符串)

原理终于清晰了。Array.prototype.sort() 的规范明确规定:如果你调用它时不传比较函数,它就会把数组的每个元素都转换成字符串,然后按字符串的码元顺序(可以理解为字典序)来排序。这是它的默认行为,也正是我这个坑的源头。那它为什么要设计成这样反直觉?这背后是一个历史性的、"为了通用"的设计取舍:sort() 这个方法,需要能给任何类型的数组排序——数字、字符串、甚至对象;而在"不知道元素到底是什么类型"的前提下,"统一转成字符串再比较",是一个能适用于所有类型的、"最通用"的默认策略。于是 JavaScript 选择了这个"通用、但对数字数组而言常常不符合直觉"的默认行为。所以你会发现,对一个字符串数组用默认 sort(),结果是完全符合直觉的(它本来就该按字典序);可一旦你对一个数字数组用默认 sort(),就掉进了"数字被当成字符串排"的坑里——而正确的做法,是给 sort() 传入一个比较函数,明确地告诉它"我要按数字大小来排"。

第二件事:正解——给 sort() 传一个比较函数

搞懂了根因——"默认按字符串排"——正解就一目了然:给 sort() 传入一个"比较函数",明确地告诉它你想要的排序规则。对数字从小到大排,经典写法就是 (a, b) => a - b。

// 正解: 给 sort() 传比较函数, 明确按数字排
const prices = [9, 80, 100, 1000, 200];

prices.sort((a, b) => a - b);   // ← 从小到大!
console.log(prices);            // [9, 80, 100, 200, 1000]  ✓ 正确!

prices.sort((a, b) => b - a);   // ← 从大到小!
console.log(prices);            // [1000, 200, 100, 80, 9]  ✓

// 比较函数的原理: sort 会拿数组里的元素两两调用 compareFn(a, b),
//   根据返回值的"正负", 决定 a 和 b 谁前谁后:
//     a - b < 0 (即 a < b): 返回负数 → a 排前面 → 从小到大
//     a - b > 0 (即 a > b): 返回正数 → a 排后面
//     a - b = 0 (即 a == b): 返回 0 → 顺序不变
//   所以 (a,b)=>a-b 就实现了"小的在前"。

// 给"对象数组"按某个字段排序, 同理:
const products = [{name: "A", price: 80}, {name: "B", price: 9}];
products.sort((a, b) => a.price - b.price);   // 按 price 从小到大
// [{name:"B",price:9}, {name:"A",price:80}]  ✓

// 按字符串排序(中文/英文), 用 localeCompare 更稳妥:
const names = ["张三", "李四", "王五"];
names.sort((a, b) => a.localeCompare(b));   // 按本地化规则排中文

这个正解的核心,是"显式地、明确地告诉 sort() 你想怎么排",而不是依赖它那个'通用但反直觉'的默认行为。比较函数 (a, b) => a - b 的原理很简单:sort() 在排序过程中,会拿数组里的元素两两地调用这个函数,然后根据它返回值的正负,来决定这两个元素谁排前、谁排后——返回负数,a 排前面;返回正数,a 排后面;返回 0,顺序不变。所以 a - b 这个表达式:当 a < b 时返回负数(a 排前)、a > b 时返回正数(a 排后),恰好就实现了"从小到大"。这套"比较函数"的机制,其实非常强大、非常灵活——它不仅能给数字排序,还能给对象数组按任意字段排序((a,b)=>a.price-b.price)、能按多个条件排序、能自定义任何你想要的排序逻辑。我之前的错误,不是 sort() 不好用,而是我偷懒、没有给它这个至关重要的比较函数,就把"该怎么排"这个关键决策,交给了它那个不靠谱的默认值。

下面这张图,对比了"不传比较函数"和"传比较函数"两条路径:

这张图的对比一目了然:左边红色那条,不传比较函数,sort() 默认把数字转成字符串、按字典序排,导致排序错乱;右边绿色那条,传入 (a,b)=>a-b,严格按数字大小排,得到正确结果。两条路的根本分野,就在"你有没有给 sort() 传那个比较函数"——一个小小的、却决定成败的细节。

第三件事:sort() 还藏着别的坑——原地修改、稳定性

填平了"字符串排序"这个最坑的坑,我顺便把 sort() 其它几个容易被忽略的"脾气"也摸了一遍,免得日后再栽:

// 坑1: sort() 会"原地修改"原数组! (不是返回一个新数组)
const arr = [3, 1, 2];
const sorted = arr.sort((a, b) => a - b);
console.log(arr);      // [1, 2, 3]  ← 原数组 arr 被改了!
console.log(sorted === arr);   // true  ← 返回的就是原数组本身!
// 如果你不想改原数组, 要先复制一份:
const sorted2 = [...arr].sort((a, b) => a - b);   // 用展开运算符复制
// (ES2023 新增了 toSorted(), 它不改原数组, 返回新数组)
const sorted3 = arr.toSorted((a, b) => a - b);    // ✓ 不改原数组

// 坑2: 比较函数必须返回"数字", 别返回 boolean!
arr.sort((a, b) => a > b);   // ✗ 错误! 返回 true/false, 而非正负数!
//   true 会被当成 1, false 当成 0, 排序结果不可靠(尤其旧引擎)!
arr.sort((a, b) => a - b);   // ✓ 永远返回数字

// 坑3: 比较函数必须"自洽" —— 否则结果未定义
//   compareFn(a,b) 和 compareFn(b,a) 的符号必须相反, 否则排序会乱套

// 坑4: 对超大数 / 混合类型要小心 a-b 溢出或 NaN
//   如果 a 或 b 可能是非数字, a-b 会得到 NaN, 排序失效, 要先校验/转换

这几个坑,让我对 sort() 这个"看似简单"的方法,有了更全面的认识。坑1(原地修改)是最容易引发连锁 bug 的:sort() 不会返回一个新的排序后的数组,而是直接修改原数组、并返回原数组本身——这意味着,如果你 sort 了一个别处还在用的数组,就会悄悄地改变它,引发意想不到的问题;不想改原数组,就要先用展开运算符 [...arr] 复制一份,或用 ES2023 新增的、不改原数组的 toSorted()。坑2(返回值类型):比较函数必须返回数字(正/负/0),绝不能图省事返回 a > b 这样的布尔值——布尔值在排序里会被错误地当成 1 和 0,导致结果不可靠。坑3、4(自洽与 NaN):比较函数的逻辑必须自洽(compare(a,b) 和 compare(b,a) 符号相反),且要小心 a-b 在非数字时得到 NaN 而让排序失效。这些坑共同提醒我:即便是 sort() 这样一个我们天天用、自以为烂熟于心的基础方法,它的细节里,也藏着不少需要认真对待的'脾气'——不去了解清楚,就可能在某个细节上栽跟头。

第四件事:不止 sort()——JavaScript 的"隐式类型转换"遍地是坑

这次 sort() 的坑,本质是"数字被悄悄转成了字符串"。而我深挖后发现,这种"悄无声息的隐式类型转换",正是 JavaScript 最臭名昭著、最容易坑人的一大类问题——sort() 只是它的一个具体表现。我把这类"隐式转换"的坑,集中扫了一遍雷:

// JavaScript 隐式类型转换的坑, 遍地都是:

// 坑1: + 号 —— 数字遇到字符串, 数字被转成字符串拼接!
console.log(1 + "2");       // "12" ! (不是 3, 数字1被转成字符串)
console.log("5" - 1);       // 4   (- 号又把"5"转成了数字! + 和 - 行为不一致!)
console.log([] + []);       // ""  (两个空数组转字符串拼接)
console.log([] + {});       // "[object Object]"

// 坑2: == 的隐式转换 —— 各种匪夷所思的相等
console.log(0 == "");       // true  ! (都转成了 0/falsy)
console.log(0 == "0");      // true  !
console.log("" == "0");     // false ! (前两个都等0, 这俩却不等, 不传递!)
console.log(null == undefined);  // true
console.log([] == ![]);     // true  ! (经典面试题, 离谱)
// 正解: 永远用 === (严格相等, 不做隐式转换)
console.log(0 === "");      // false ✓ 符合直觉

// 坑3: 条件判断里的"falsy"隐式转换
if ("0") { }   // 进入! "0"是非空字符串, 为 truthy (但 "0"==false 又为 true...)
if (0) { }     // 不进入, 0 是 falsy

// 坑4: 数组/对象转字符串、转数字, 处处是"惊喜"
console.log(Number("123abc"));  // NaN
console.log(parseInt("123abc")); // 123 (parseInt 容忍后缀!)
console.log(Number([1,2]));      // NaN
console.log(Number([5]));        // 5  (单元素数组能转!)

这一扫雷,让我对 JavaScript 的"隐式类型转换"生出了深深的敬畏(和畏惧)。JavaScript 为了"灵活"和"宽容",设计了一套极其复杂、且常常反直觉的隐式类型转换规则——它会在你意想不到的地方,自作主张地把一种类型,悄悄转换成另一种类型,而转换的结果,常常出乎意料。坑1(+ 号):+ 遇到字符串会变成"拼接"(1 + "2" 是 "12"),而 - 却会把字符串转成数字("5" - 1 是 4),同样的操作数、不同的运算符,行为天差地别。坑2(== 的转换)更是 JavaScript 的"耻辱柱"——0 == "" 为真、[] == ![] 为真,各种匪夷所思、甚至不满足传递性的相等判断,根源都是 == 做了隐式转换;正解是永远用 ===(严格相等,不做任何隐式转换)。这些坑,和我这次的 sort() 坑,本质完全一致——都是"JavaScript 在背后,悄悄地、自作主张地,做了一次我没有预期到的类型转换"。理解了这一点,我对待 JavaScript 的态度就变了:在这门以'宽容'著称、却也因此处处暗藏隐式转换的语言里,我必须时刻保持警惕,对那些'类型可能被悄悄转换'的地方,格外小心。把这些常见的隐式转换坑整理成一张表:

第五件事:把"默认行为"当成"必须确认的事",而非"理所当然的事"

这次踩坑,在方法论层面也给了我一个重要的提醒——它改变了我对待各种 API"默认行为"的态度。我把这个反思,沉淀成了几条使用任何 API 的习惯:

// 对待 API "默认行为" 的正确态度:

// 习惯1: 用一个方法前, 主动去查"它的默认行为是什么"
//   sort() 默认按字符串排, parseInt 默认十进制(但有坑), JSON.stringify 默认丢 undefined...
//   别想当然地以为默认行为"就是我以为的那样"。

// 习惯2: 对"有默认值/默认行为"的参数, 倾向于"显式传入"
arr.sort((a, b) => a - b);   // 显式传比较函数, 别依赖默认
parseInt("08", 10);          // 显式传进制 10, 别依赖默认(老引擎"08"可能被当八进制!)
[1,2,3].reduce((a,b)=>a+b, 0); // 显式传初始值 0, 别依赖默认

// 习惯3: 对结果有疑问时, 立刻在控制台"亲自验证一下"
//   花 10 秒在控制台跑一下 [9,80,100].sort(), 就能在上线前发现这个坑!

// 习惯4: 写测试时, 专门测"边界数据"
//   排序: 测多位数 vs 个位数(9 vs 80)、负数、相等元素 ——
//   如果当初测了 [9, 80, 100] 而非 [1, 2, 3], 这坑上线前就暴露了!

// 核心: API 的"默认行为", 是设计者替你做的一个"假设性选择",
//   它【不一定】符合你当前场景的需求。把它当成"需要确认的事",
//   而非"理所当然就对的事", 是避开这类坑的关键习惯。

这几条习惯,标志着我对待 API 的心态,从"想当然地信任"变成了"审慎地确认"。它的核心,是一个重要的转变:把 API 的"默认行为",从"理所当然就该是我以为那样"的假设,变成"需要我主动去确认一下"的事项。我这次栽跟头,根子上就是我对 sort() 的默认行为,做了一个"想当然"的假设——我以为它默认就是按数字大小排的,却从没去确认过、也从没去查过它真实的默认行为。而 API 的默认行为,本质上是"设计者在设计时,替你做的一个假设性的、通用的选择";这个选择,不一定符合你当前这个具体场景的需求(比如 sort() 默认按字符串排,就不符合"数字排序"这个场景)。所以,正确的态度,是不把默认行为当成"理所当然就对的",而是:用一个方法前,主动查清它的默认行为(习惯1);对有默认值的参数,倾向于显式传入、不依赖默认(习惯2);有疑问时,花十秒在控制台亲自验证一下(习惯3);写测试时,专门测能暴露问题的边界数据(习惯4)。这次的坑,如果我当初测试时,用的是 [9, 80, 100] 这种"能暴露字符串排序问题"的数据,而不是恰好不会出错的 [1, 2, 3],它在上线前就会原形毕露。把"想当然信任默认"和"审慎确认默认"两种态度对比成一张表:

一张"用 sort() 排序该怎么做"的决策图

把这次踩坑沉淀成一张图。每当你要给一个数组排序时,照着它走:

这张图的主线:无论排什么,都显式传比较函数——数字用 a-b,对象按字段相减,字符串用 localeCompare;要保留原数组就先复制或用 toSorted();最后用"多位数 vs 个位数"这种能暴露问题的数据验证一遍。把"绝不裸调 sort()"变成肌肉记忆,这个经典坑就再也碰不到你。

我立下的几条排序与 API 使用规矩

这次"9 元排在 80 元后面"的线上事故后,我给自己立了几条规矩:

1. sort() 永远传比较函数:绝不裸调 sort(),数字用 (a,b)=>a-b,对象按字段相减,字符串用 localeCompare。
2. 比较函数返回数字:比较函数必须返回正/负/0 的数字,绝不返回 a>b 这样的布尔值。
3. 注意 sort 原地修改:记住 sort() 会改原数组,要保留原数组就先 [...arr] 复制或用 toSorted()。
4. 永远用 ===:用严格相等 ===,避开 == 那一整套匪夷所思的隐式转换。
5. 警惕隐式类型转换:对 +、比较、条件判断里可能发生的隐式转换保持警惕,必要时显式转换类型。
6. 查清 API 默认行为:用一个方法前主动查它的默认行为,对有默认值的参数倾向显式传入。
7. 用边界数据测:测排序等功能,专门用"能暴露问题"的数据(多位数、负数、相等元素),别只测恰好不出错的简单值。

这几条里,第一条"sort() 永远传比较函数"是用一次线上事故换来的、最该刻进肌肉记忆的铁律。而贯穿所有规矩的那条主线,是对"想当然"的警惕。我这次栽跟头,根子上就两个字——"想当然":我想当然地以为 sort() 默认就是按数字排的,想当然地以为这么基础的方法不会有坑,想当然地用 [1,2,3] 这种简单数据测了一下没问题就放心了。正是这一连串的"想当然",让我对一个其实很经典、很有名的坑,毫无防备。'想当然',是程序员最危险的思维习惯之一——它让我们跳过了'确认'这个关键步骤,把一个个'未经验证的假设',当成了'确凿无疑的事实',然后在某个假设不成立的地方,猝不及防地栽下去。对'想当然'保持警惕、把'假设'变成'确认',是避开无数这类坑的根本心法。

写在最后:把"我以为"换成"我确认过"

这次被 sort() 坑到的经历,虽然问题不大,却给了我一个朴素而深刻的提醒:在编程的世界里,"我以为"和"我确认过",是两种截然不同的、甚至天差地别的状态;而我们栽的很多跟头,恰恰源于把'我以为'当成了'我确认过',在一个其实从未真正核实过的假设上,建起了自己的代码。我"以为" sort() 按数字排,"以为"它不会有坑,可这些"以为",我从来没有真正去"确认"过——我没查过文档,没在控制台验证过,没用边界数据测过。而正是这些未经确认的"以为",在上线后,变成了一个个真实的 bug。"我以为"是一种基于直觉、记忆、或想当然的猜测;而"我确认过",是一种基于查证、验证、实测的事实——前者廉价却不可靠,后者多花一点功夫,却坚实可信。

想通这一点,我对"确认"这个朴素的动作,生出了一份新的尊重。编程,在很大程度上,是一项需要极度严谨的工作——因为代码不会"理解你的意图",它只会"忠实地执行它真实的逻辑";而你脑中那些"我以为"的假设,只要有一个和代码"真实的逻辑"不符,就可能酿成一个 bug。所以,一个可靠的程序员,会有一种近乎本能的'确认'习惯:对那些'可能会错、且错了影响不小'的关键假设,他不满足于'我以为是这样',而会多花几分钟,去'确认一下到底是不是这样'——查一下文档、跑一下验证、测一下边界。这种"确认"的习惯,看起来"慢"了一点、"麻烦"了一点,可它换来的,是把无数潜在的 bug,扼杀在它们变成线上事故之前。多一分'确认'的严谨,就少一分'想当然'的风险;而这,正是'能写出能跑的代码'和'能写出可靠的代码'之间,一道重要的分水岭。

所以,如果你也想写出更可靠的代码、少踩一些"想当然"的坑,我想把这次踩坑最想说的话送给你:对你代码里那些关键的假设,请努力地,把"我以为"换成"我确认过"。当你用一个不太熟的 API 时,别"以为"它怎么工作,去查一下、验证一下;当你写一段关键逻辑时,别"以为"它没问题,用能暴露问题的数据测一下;当你对一个结果拿不准时,别"猜",花十秒亲自跑一下看看。因为代码是不留情面的,它只认'真实的逻辑',不认你'美好的想象';而把每一个关键的'我以为',都用查证和验证,夯实成'我确认过',正是你能让自己的代码,从'碰运气地对'走向'扎实地对'的、那条最朴素也最可靠的路。那个把 9 元排在 80 元后面的 sort(),最终教给我的,正是这份对"确认"的敬重——它让我懂得,在编程里,真正可怕的不是"不会",而是"自以为会却没确认";而对每一个"我以为",都多问一句"真的吗、我确认过吗",正是一个程序员走向严谨与可靠的、最重要的一步。

—— 别看了 · 2026