中文排序不能直接用localeCompare，因其默认按Unicode码点排序（如“张”U+5F20排在“啊”U+554A前），违背拼音习惯；而Intl.Collator显式指定'zh-Hans'等选项可精准实现拼音逐级比较，支持复用、数字混排与多级排序。
中文排序为什么不能直接用 localeCompare
因为 localeCompare 在中文场景下默认按 Unicode 码点排序，「张」（U+5F20）会排在「啊」（U+554A）前面，完全违背拼音习惯；且多字段串联调用时无法复用排序逻辑，性能差、语义松散。
而 Intl.Collator 支持显式指定 zh-Hans 语言标签 + numeric: true + sensitivity: 'base'，能真正按拼音首字母→声调→字形逐级比较，且实例可复用，避免重复解析排序规则。
创建支持拼音排序的 Collator 实例要注意什么
必须显式传入 locale 和关键选项，否则浏览器可能 fallback 到系统默认行为（比如 macOS 上可能走笔画排序）：
-
new Intl.Collator('zh-Hans', { numeric: true, sensitivity: 'base' })—— 最常用组合，兼容数字混排（如「第1章」「第10章」），忽略大小写与标点差异 - 若需区分声调（如「ma1」≠「ma2」），加
caseFirst: 'upper'并设sensitivity: 'accent'，但实际中文列表极少需要 - 避免只传
'zh'：部分旧版 Chrome 对'zh'解析不稳定，'zh-Hans'更可靠 - 不要在循环里反复 new：每个实例内部缓存了 ICU 排序权重表，复用可提升 3–5 倍多级排序性能
多级排序时如何组合字段且不破坏拼音语义
不能简单链式调用 a.localeCompare(b) || c.localeCompare(d)，那会丢失 Collator 的拼音上下文。正确做法是预计算每行的排序键（sort key），再用单次比较：
const collator = new Intl.Collator('zh-Hans', { numeric: true, sensitivity: 'base' });
<p>function getSortKey(item) {
// 拼音主序：姓名；次序：部门（拼音）；末序：入职时间（数值）
return [
collator.compare(item.name, ''), // 避免 undefined 导致 compare 报错
collator.compare(item.dept || '', ''),
item.joinDate || 0
];
}</p><p>list.sort((a, b) => {
const keyA = getSortKey(a);
const keyB = getSortKey(b);
for (let i = 0; i </p>
注意：collator.compare() 返回 -1/0/1，但作为排序键的一部分时，要确保所有字段类型一致——字符串字段用 compare 结果，数值字段直接用原值，否则混合比较会出错。
遇到简繁体混合或带括号别名时怎么处理
Collator 默认不自动转换简繁体，「张三」和「張三」会被视为不同字；括号内内容（如「李四（技术部）」）也会参与拼音计算，导致「（技术部）」被当作「kuan」开头。
- 简繁体统一：前端可预先用
zh-convert类库转为纯简体再排序，或后端返回标准化字段（如name_pinyin） - 过滤括号干扰：对字段做正则清洗，例如
item.name.replace(/（[^）]*）/g, '')，再喂给 collator - 极端情况（如「重庆」vs「重慶」）建议加兜底字段：服务端提供
pinyin_key，前端仅作 fallback 使用，避免 JS 运行时拼音转换拖慢首屏
拼音排序不是黑盒魔法，Collator 的能力边界很清晰：它只负责“按指定语言规则比较两个字符串”，预处理和字段设计仍需开发者把控。尤其当数据来自多个渠道、含非标准字符时，靠一个 new Intl.Collator 解决不了所有问题。
