如何借助 Intl.Collator 实现含拼音及部首等本地化语义的复杂中文数据列表精准排序

中文排序需显式设置 collation: 'pinyin' 并配 sensitivity: 'base' 和 numeric: true，否则默认 UCA 排序不符合拼音习惯；部首/笔画排序须自定义映射表实现。

中文排序不能只靠 locale: 'zh-CN' 简单设置

直接传 new Intl.Collator('zh-CN') 对中文字符串排序，结果往往不符合预期：「张」可能排在「李」前面，「苹果」跑到了「香蕉」之后。这是因为默认的 zh-CN 仅启用基础 Unicode 排序（UCA），不激活拼音、笔画、部首等中文特有排序规则。浏览器实际行为取决于底层 ICU 数据版本，Chrome 和 Safari 表现可能不一致，且完全忽略《GB/T 13418-92》或《GB18030》中定义的部首/笔画次序。

必须显式启用拼音排序：使用 sensitivity 和 numeric 配合 collation

中文姓名、商品名等需按读音排序时，光靠 locale 不够，关键要设 collation: 'pinyin' —— 这是 ICU 提供的扩展排序类型，不是所有浏览器都支持，但 Chrome 90+、Edge 90+、Safari 17+ 已稳定支持。同时需配合以下参数：

• sensitivity: 'base'：忽略大小写和音调（如「zhang」、「Zhāng」、「ZHANG」视为等价）
• numeric: true：保证「第1名」排在「第10名」之前，避免字典序错乱
• 不要设 caseFirst 或 alternate，它们会干扰拼音主序

示例：

const collator = new Intl.Collator('zh-CN', {  collation: 'pinyin',  sensitivity: 'base',  numeric: true});['张三', '李四', '王五'].sort(collator.compare); // → ['李四', '王五', '张三']（按拼音 li, wang, zhang）

部首/笔画排序需 fallback 到自定义映射表，Intl.Collator 不支持

目前没有任何浏览器实现 collation: 'radical' 或 collation: 'stroke'。如果你的业务明确要求按《康熙字典》214 部首顺序或总笔画数排序（例如古籍索引、汉字教学系统），Intl.Collator 无能为力，必须手动预处理：

• 用已验证的汉字部首/笔画数据源（如 chinese-character-db npm 包或 OpenCC 的字典）生成映射表
• 对每个汉字查出「部首编号 + 剩余笔画数」，拼成可排序的元组，如「汉」→ [103, 2]（氵部第103号，共2画）
• 排序时先比部首编号，再比剩余笔画，最后 fallback 到拼音

注意：同一部首内，《康熙》和《新华字典》的笔画计算方式不同（是否含部首本身），必须与业务规范对齐。

多级排序组合时，别把 collator 当万能 compare 函数

真实列表常需「先按分类字段分组，组内再按中文名拼音排序」。此时不能直接 arr.sort(collator.compare)，因为 compare 只处理字符串，无法感知其他字段。正确做法是写完整比较函数：

const nameCollator = new Intl.Collator('zh-CN', { collation: 'pinyin', sensitivity: 'base' });data.sort((a, b) => {  if (a.category !== b.category) {    return a.category.localeCompare(b.category); // 分类用默认 localeCompare 即可  }  return nameCollator.compare(a.name, b.name); // 同组内才用拼音 collator});

容易被忽略的是：如果 a.name 或 b.name 是 null、undefined、数字或对象，compare() 会静默转成字符串（如 undefined → 'undefined'），导致排序错位。务必提前清洗或提供默认值。