核心是sort()行为受引擎实现、参数、数据特征和语言环境共同影响，非“写对就稳”；常见表现为中文/重复值/混排时Chrome正常而Safari或旧Node错乱，需用最小案例比对多端输出定位差异。
识别这类跨端 Bug 的核心，是意识到 sort() 的行为不只取决于你写的比较函数，还受浏览器引擎实现、是否传参、数据特征和语言环境共同影响。它不是“写对就稳”，而是“看似正常，一换环境就翻车”。
看排序结果是否违反直觉且不可复现
当数组含重复值（如多个相同姓名）、中文/日文字符串、或数字与字符串混排时，若在 Chrome 中顺序合理，但在 Safari 旧版或某些 Electron 内核中出现错位、颠倒、甚至死循环，就要怀疑稳定性或 locale 处理差异。
- 比如按字段
name排序，两个对象{name: "张", id: 1}和{name: "张", id: 2}在 Chrome 里保持id原序，但在 IE 或老版 Node.js 中可能互换——这不是 bug，是规范允许的“不稳定” - 再如
["苹果", "香蕉", "橙子"].sort()在无 compareFn 时，Chrome 和 Firefox 可能碰巧排对，但 Safari 10 之前会按 Unicode 码点乱序（"香"U+9999 > "苹"U+82F9 > "橙"U+6A59），结果是 ["橙子", "苹果", "香蕉"] 或完全打乱
检查是否隐式依赖了特定引擎的默认行为
常见误用包括：没传比较函数却指望数字升序、用 a - b 排序但数组含 null/undefined/"1" 字符串、或直接对对象数组调 sort() 期望按某个属性排。
-
[10, 2, 1].sort()→[1, 10, 2]（字符串化后比较），这是所有浏览器一致的“正确错误”，但常被当成环境差异 -
[{v: 2}, {v: 10}].sort((a,b) => a.v - b.v)在 V8 和 SpiderMonkey 都正常，但若比较函数里有console.log或异步操作，V8 可能报错或卡住，而其他引擎表现不同
验证 locale 敏感排序是否实际生效
用 Intl.Collator 或 String.prototype.localeCompare 时，不同环境支持粒度不同：Safari 12+ 支持 numeric: true，但 Safari 10–11 不支持；Node.js 12 默认不加载完整 ICU 数据，localeCompare("a", "b", "zh") 可能退化为英文排序。
- 测试方法：构造含数字的字符串数组，如
["item2", "item10", "item1"]，用sort((a,b) => a.localeCompare(b, "en", {numeric:true}))，在 Chrome/Firefox 正确返回["item1","item2","item10"]，但在旧 Safari 或未配 ICU 的 Node 中仍按字典序变成["item1","item10","item2"] - 检测兼容性：
typeof Intl !== 'undefined' && typeof Intl.Collator === 'function'是基础，还需实测关键 case，不能只查构造函数存在
用最小可复现案例隔离引擎差异
不要靠用户反馈猜问题。准备三组输入，在目标环境中运行并比对输出：
- 纯 ASCII 数字数组：
[3, 11, 2]—— 测默认行为是否一致 - 含重名对象数组：
[{n:"李"}, {n:"李"}, {n:"王"}]—— 测稳定性 - 中文拼音数组：
["张三", "李四", "王五"]，配合new Intl.Collator("zh").compare—— 测 locale 支持深度
记录每组在 Chrome、Firefox、Safari、WebView（Android/iOS）中的输出。差异即 Bug 根源，而非“某浏览器有问题”。
