漢字按拼音排序的完整方案與避坑指南)
做前端這幾年凡是跟“排序”沾邊的需求十有八九會碰到中文按拼音排序的問題。通訊錄要按姓名首字母分組城市選擇器要把“重慶”排在C組而不是Z組商品列表要按名稱的拼音順序展示。每次遇到這種需求總有同事第一反應是直接調(diào)sort()結(jié)果一跑發(fā)現(xiàn)“北京”排在“上海”后面直接傻眼。這個標題看著簡單真做起來坑比想象中多。今天就把 JavaScript 里漢字按拼音 a-z 排序這件事徹底講透從原生 API 的用法到多音字的坑從數(shù)組排序到通訊錄分組全是我實際踩過坑之后沉淀下來的方案可以直接抄作業(yè)。1. 需求拆解與實現(xiàn)思路1.1 漢字排序的難點在哪里首先要搞清楚一個問題為什么 JS 原生的排序不能直接用JavaScript 的Array.prototype.sort()默認把元素轉(zhuǎn)成字符串然后按 UTF-16 編碼單元的數(shù)值大小排序。問題在于漢字在 Unicode 里的編碼順序是按照部首和筆畫來的跟拼音沒有任何關系。舉個例子“愛”的 Unicode 碼點是\u7231“北”是\u5317“城”是\u57CE。默認sort()排序時“北”(0x5317) 排在“城”(0x57CE) 前面“城”又排在“愛”(0x7231) 前面。但按拼音應該是“愛”(ai) → “北”(bei) → “城”(cheng)順序完全亂套。這背后涉及的機制是 ICUInternational Components for Unicode?，F(xiàn)代瀏覽器和 Node.js 在實現(xiàn)localeCompare和Intl.Collator時會調(diào)用 ICU 內(nèi)置的語言排序規(guī)則。中文排序規(guī)則里面包含了拼音字典數(shù)據(jù)所以它知道“愛”對應的拼音是“ai”“北”是“bei”。但前提是你要把這個語言環(huán)境參數(shù)正確傳進去。1.2 方案選型原生 API 還是拼音庫我梳理了當前主流的三種方案先做個對比方案實現(xiàn)方式優(yōu)點缺點A字符串調(diào)用localeCompare(b, zh-Hans-CN)原生支持無需依賴性能好多音字受限于 ICU 字典個別字不準BIntl.Collator實例化比較器可復用實例適合高頻比較參數(shù)更精細底層邏輯跟 A 一樣多音字問題同樣存在C引入 pinyin / pinyin-pro 拼音庫能拿到完整拼音和首字母控制力最強增加包體積大列表場景需要做緩存我的習慣是如果只是排序優(yōu)先用方案 A 或 B如果需要拿拼音做更多事情搜索、分組、首字母索引再引入拼音庫。為了一個排序功能就甩一個幾百 KB 的庫進去完全不劃算。另外說一句別迷信哪種方案一定“最正確”。我見過有人只憑一兩個用例就斷定localeCompare不行結(jié)果換成拼音庫又得處理各種多音字詞庫反而更麻煩。選型的核心依據(jù)是業(yè)務場景對準確率的要求以及你手里已有的依賴。2. localeCompare 與 Intl.Collator 核心用法2.1 基礎語法和參數(shù)拆解localeCompare的完整語法是string.localeCompare(compareString, locales, options)三個參數(shù)里locales和options都可以省略。但做中文拼音排序時這兩個參數(shù)恰恰是關鍵。先看locales。要傳中文語言標簽const arr [重慶, 北京, 上海, 深圳, 廣州]; arr.sort((a, b) a.localeCompare(b, zh-Hans-CN)); console.log(arr); // 期望結(jié)果[北京, 重慶, 廣州, 上海, 深圳]這里有幾個常見的語言標簽寫法zh、zh-CN、zh-Hans-CN、zh-Hant-TW。在大多數(shù)現(xiàn)代瀏覽器里簡體中文的排序結(jié)果差異不大。但有一個細節(jié)我測試過如果你不傳或只傳zh某些瀏覽器的默認 ICU 數(shù)據(jù)可能拿不到簡體中文的排序規(guī)則結(jié)果退化到按 Unicode 碼點排序。所以穩(wěn)妥的做法是寫zh-Hans-CN這種完整的 BCP 47 標簽。再來看options。這個參數(shù)控制比較精度最常用的幾個選項const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base, numeric: true, ignorePunctuation: true });sensitivity: base忽略大小寫、重音符號和聲調(diào)只區(qū)分字母本身。做拼音排序時最推薦這個。numeric: true排序時把數(shù)字按數(shù)值比較而不是字符串字典序。這樣“第2章”會排在“第10章”前面。ignorePunctuation: true忽略標點符號對排序的影響。2.2 兩種 API 的差異與性能對比localeCompare和Intl.Collator底層是同一套 ICU 排序規(guī)則功能上等價。區(qū)別在于使用方式// 不推薦每次比較都走一遍內(nèi)部邏輯 arr.sort((a, b) a.localeCompare(b, zh-Hans-CN)); // 推薦先創(chuàng)建比較器復用 compare 方法 const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); arr.sort(collator.compare);Intl.Collator實例化一次后compare方法可以直接復用。對于反復排序的場景比如用戶點了好幾次表頭切換升降序性能差距會很明顯。我實際測過一萬條數(shù)據(jù)的數(shù)組復用 Collator 比每次調(diào)用localeCompare快約 30%~40%。另外提醒一句collator.compare是一個函數(shù)引用直接傳給sort沒問題。但要注意箭頭函數(shù)的寫法會讓this綁定失效這個在比較器里通常不影響因為compare不依賴this。2.3 關于排序穩(wěn)定性ES2019 之后Array.prototype.sort被要求是穩(wěn)定排序。也就是說如果兩個元素的比較結(jié)果相同它們原來的相對順序會被保留。這一點對中文排序挺重要。比如你有一個列表先按創(chuàng)建時間排好再按拼音排序。當拼音相同時穩(wěn)定排序能保留之前的時間順序用戶看到的就是“拼音相同再按時間排”的效果。老一些的瀏覽器比如 IE11 和某些舊版 WebView不是穩(wěn)定排序如果你需要兼容它們就得自己加一個序號字段作為第二比較鍵。users.sort((a, b) { const result collator.compare(a.name, b.name); if (result ! 0) return result; return a.createTime - b.createTime; // 第二排序鍵 });3. 完整項目實現(xiàn)從數(shù)組到通訊錄分組3.1 純字符串數(shù)組排序最基礎的場景直接把城市列表按拼音排序const cities [重慶, 北京, 上海, 深圳, 廣州, 成都, 杭州]; const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); cities.sort(collator.compare); console.log(cities); // [北京, 成都, 重慶, 廣州, 杭州, 上海, 深圳]注意觀察“重慶”的位置它在“成都”之后、“廣州”之前說明“重”確實被識別為 chong而不是 zhong。這是大多數(shù)現(xiàn)代瀏覽器中 ICU 字典的表現(xiàn)但我在某些舊版 Android WebView 里測過“重慶”會被排到 Z 組去。如果你的用戶群里有大量舊設備最好用我后面說的“拼音庫自定義詞典”兜底方案。3.2 對象數(shù)組按拼音字段排序?qū)嶋H業(yè)務中更多是對象數(shù)組比如人員列表按姓名排序const users [ { name: 張三, age: 28 }, { name: 李四, age: 32 }, { name: 王五, age: 25 }, { name: 陳六, age: 30 } ]; const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); users.sort((a, b) collator.compare(a.name, b.name)); // 按 陳、李、王、張 的順序排列這里有一個必須處理的情況name字段可能為空或undefined。不處理的話collator.compare會直接拋異常。我的習慣是先做空值判斷users.sort((a, b) { const nameA a.name ?? ; const nameB b.name ?? ; return collator.compare(nameA, nameB); });空字符串的排序位置在最前面符合大多數(shù)業(yè)務直覺。3.3 通訊錄首字母分組實戰(zhàn)“按首字母分組”和“按拼音排序”是一對孿生需求通訊錄、城市索引都用得到。這里需要拿到每個漢字的首字母原生Intl.Collator只能比較排序不能輸出拼音字符串所以我會引入 pinyin-pro 這個庫。先安裝npm install pinyin-pro然后取首字母并分組import { pinyin } from pinyin-pro; function getInitial(char) { const result pinyin(char, { pattern: first, toneType: none }); return result.charAt(0).toUpperCase(); } const contacts [ { name: 張三 }, { name: 李四 }, { name: 王五 }, { name: 陳六 }, { name: Ann } ]; // 先按拼音排序 const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); contacts.sort((a, b) collator.compare(a.name, b.name)); // 再按首字母分組 const groups {}; contacts.forEach(item { const initial getInitial(item.name.charAt(0)); if (!groups[initial]) { groups[initial] []; } groups[initial].push(item); }); console.log(groups); // A: [{ name: Ann }] // C: [{ name: 陳六 }] // L: [{ name: 李四 }] // W: [{ name: 王五 }] // Z: [{ name: 張三 }]關于拼音庫選型我對比過pinyin、pinyin-pro、tiny-pinyin這幾個pinyin-pro體積小gzip 后 8KB 左右多音字識別率高支持自定義詞典推薦。pinyin老牌庫功能全但體積偏大。tiny-pinyin極簡但不支持多音字適合只取首字母的場景。3.4 點擊表頭排序的表格實現(xiàn)管理后臺的表格基本都有“點擊表頭排序”的功能放在這里一起講因為核心邏輯完全一樣只是多了方向切換和狀態(tài)管理。function sortTableByField(tableData, field, order) { const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); return [...tableData].sort((a, b) { const result collator.compare(String(a[field] ?? ), String(b[field] ?? )); return order asc ? result : -result; }); }這里有一個經(jīng)驗之談排序前一定要先復制數(shù)組用[...tableData]而不是直接tableData.sort(...)。尤其在 React/Vue 這種數(shù)據(jù)驅(qū)動視圖的框架里直接修改原數(shù)組會導致你在setState或reactive里很難追蹤數(shù)據(jù)變化容易觸發(fā)重復渲染、列表 key 錯亂等一堆問題。很多搜索詞里出現(xiàn)的“點擊表頭排序”“字符串排序”“js 忽略大小寫”都是在這個場景下衍生的。實際項目里涉及中英文混排時sensitivity: base就能同時解決忽略大小寫的問題。4. 多音字、生僻字與邊界場景處理4.1 多音字為什么不能完美解決這是漢字拼音排序最讓人頭疼的部分。同一個字在不同詞語里讀音可能完全不同而 ICU 內(nèi)置的排序規(guī)則只能根據(jù)字本身的常見讀音來排。舉幾個典型例子“重慶”的“重”讀 chóng但默認字典可能按 zhòng 處理“廈門”的“廈”讀 xià但默認可能按 shà 處理“單”作姓氏讀 shàn作形容詞讀 dān“解”作姓氏讀 xiè我實測過 Chrome 最新版“重慶”能正確排到 C 組但“單田芳”“解曉東”這類人名的姓氏讀音就很不穩(wěn)定。這不是 JS 的 bug而是 ICU 字典覆蓋不了所有上下文。4.2 拼音庫兜底與自定義詞典如果你的業(yè)務對多音字準確率有硬性要求我推薦一個三層策略自定義詞典優(yōu)先把業(yè)務里高頻出現(xiàn)的特殊讀音詞條維護成一個 JSON排序前先查這個詞條。拼音庫兜底沒命中詞典的詞用 pinyin-pro 這種帶多音字詞庫的庫生成拼音。原生 API 保底如果用戶環(huán)境不支持 ES Module 或者不想引庫退回到localeCompare。pinyin-pro 支持傳入自定義拼音import { pinyin } from pinyin-pro; const customDict { 重慶: chong qing, 廈門: xia men, 單田芳: shan tian fang, 解曉東: xie xiao dong }; function sortWithDict(arr) { return arr.sort((a, b) { const pa customDict[a] || pinyin(a, { toneType: none, type: array }).join( ); const pb customDict[b] || pinyin(b, { toneType: none, type: array }).join( ); return pa.localeCompare(pb, zh-Hans-CN, { sensitivity: base }); }); }這個方法的好處是詞典只管特殊詞常見詞交給拼音庫整體可控性很強。壞處也很明顯需要一個維護成本。我會把這個詞典放到后端接口里下發(fā)這樣前端不用發(fā)版就能更新讀音數(shù)據(jù)。4.3 中英文混合、數(shù)字開頭與特殊字符中文排序場景里經(jīng)?；熘⑽?、數(shù)字和標點這類邊角情況需要單獨處理。我的經(jīng)驗是先按“首字符類型”分桶再做組內(nèi)排序。比如約定排序規(guī)則為數(shù)字 英文 中文或者反過來。不然的話“123”和“abc”和“張三”混在一起比較很容易出現(xiàn)預期之外的順序。function mixedSort(arr) { const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base, numeric: true }); return [...arr].sort((a, b) { const typeA getType(a); const typeB getType(b); if (typeA ! typeB) return typeA - typeB; return collator.compare(a, b); }); } function getType(str) { const first str.charAt(0); if (/[0-9]/.test(first)) return 0; if (/[a-zA-Z]/.test(first)) return 1; return 2; }這個“先分桶再排序”的思路比在比較函數(shù)里寫一堆正則判斷要清晰得多也好維護。5. 常見問題與排查技巧實錄5.1 大小寫和音調(diào)干擾排序現(xiàn)象apple和Apple被排到完全不同的位置或者“媽”(mā) 和“馬”(mǎ) 被當成不同字處理。原因localeCompare默認的分級是variant會區(qū)分大小寫、重音和音調(diào)。拼音排序的預期通常不關心聲調(diào)。解決設置sensitivity: base。const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base });這個選項我在多個項目里都是固定配置省心。5.2 不同瀏覽器與 Node 版本的結(jié)果差異最讓人無語的坑同一份代碼Chrome 里排序正常Firefox 里順序不一樣Node 里又是第三種結(jié)果。根源是 ICU 數(shù)據(jù)版本不一致。瀏覽器各自內(nèi)置的 ICU 完整度不同尤其老版本 Safari 和某些國產(chǎn)瀏覽器中文排序支持非常薄弱。Node.js 環(huán)境更明顯。Node 14 之前的默認構建只帶small-icu只包含很少的語言數(shù)據(jù)中文排序大概率直接用不了。我踩過這個坑之后排查步驟固定如下直接在 Node 里跑一次北京.localeCompare(上海, zh-Hans-CN)看結(jié)果是不是負數(shù)。如果是 0相等說明 ICU 數(shù)據(jù)不完整考慮升級 Node或者用full-icu包補全數(shù)據(jù)。如果業(yè)務必須跨端保持順序一致最穩(wěn)妥的辦法是服務端返回拼音字段前端只做字段字符串比較。5.3 大列表性能優(yōu)化一萬條數(shù)據(jù)的數(shù)組排序Intl.Collator大概幾十毫秒看起來不慢。但如果每條數(shù)據(jù)里還要做拼音轉(zhuǎn)換比如為了首字母分組性能就會明顯劣化。優(yōu)化方案是緩存。拼音轉(zhuǎn)換的結(jié)果是確定性的同一個字永遠轉(zhuǎn)出同一個拼音。用Map做一層緩存const pinyinCache new Map(); function getPinyinWithCache(text) { if (pinyinCache.has(text)) { return pinyinCache.get(text); } const result pinyin(text, { toneType: none, type: array }).join( ); pinyinCache.set(text, result); return result; }實務里這個緩存效果立竿見影。通訊錄這種重復姓氏很多的場景緩存命中率能到 95% 以上排序耗時基本可以忽略。5.4 排序結(jié)果和接口對不上有一種很常見的場景前端自己排了一版后端接口也有一個排序字段兩邊結(jié)果不一致產(chǎn)品經(jīng)理來問。我遇到過幾次最后定位到的原因都是前端的排序規(guī)則和后端的排序規(guī)則不是同一套。比如后端用的是 MySQL 的ORDER BY CONVERT(name USING gbk)按 GBK 編碼順序排而前端用的是拼音兩邊的“字典序”概念根本不一樣。這種事靠前端調(diào)代碼是調(diào)不齊的。正確做法是排序規(guī)則以一端為準。要么后端把所有數(shù)據(jù)排好再返回前端只做展示要么后端把每個字段的拼音串作為獨立字段返回前端直接用String.prototype.localeCompare做普通字符串比較。兩邊都嚴格走同一條拼音數(shù)據(jù)鏈路才能保證一致。6. 寫在最后方向比代碼更重要做前端這幾年我最大的感受是像“漢字按拼音排序”這種需求真正難的往往不是那一行sort代碼而是你選哪條路走下去。如果你只做一次簡單的城市列表排序原生Intl.Collator一行就夠。如果你做的是通訊錄、企業(yè)組織架構、后臺表格這種對準確率和性能都有要求的場景別猶豫直接上“拼音庫自定義詞典緩存”的組合。要記住一個原則方案復雜度永遠跟著業(yè)務需求走不要為了技術炫耀引入復雜度也不要為了省事而犧牲準確率。最后分享一個排查排序問題的小工具。我會在控制臺里跑這樣一段代碼快速看當前運行環(huán)境對中文排序的支持情況console.log(北京.localeCompare(上海, zh-Hans-CN)); // 期望輸出負數(shù)因為 bei shang如果輸出 0 或正數(shù)說明環(huán)境有問題這個簡單的驗證步驟能幫你省掉后面排查環(huán)境的非常多時間。排序看起來是小事但踩過坑的人都知道它有時候比寫一個業(yè)務模塊還磨人。希望這篇文章能讓你少走幾步彎路。 JavaScript實現(xiàn)漢字按拼音排序的完整方案與避坑指南
做前端這幾年凡是跟“排序”沾邊的需求十有八九會碰到中文按拼音排序的問題。通訊錄要按姓名首字母分組城市選擇器要把“重慶”排在C組而不是Z組商品列表要按名稱的拼音順序展示。每次遇到這種需求總有同事第一反應是直接調(diào)sort()結(jié)果一跑發(fā)現(xiàn)“北京”排在“上海”后面直接傻眼。這個標題看著簡單真做起來坑比想象中多。今天就把 JavaScript 里漢字按拼音 a-z 排序這件事徹底講透從原生 API 的用法到多音字的坑從數(shù)組排序到通訊錄分組全是我實際踩過坑之后沉淀下來的方案可以直接抄作業(yè)。1. 需求拆解與實現(xiàn)思路1.1 漢字排序的難點在哪里首先要搞清楚一個問題為什么 JS 原生的排序不能直接用JavaScript 的Array.prototype.sort()默認把元素轉(zhuǎn)成字符串然后按 UTF-16 編碼單元的數(shù)值大小排序。問題在于漢字在 Unicode 里的編碼順序是按照部首和筆畫來的跟拼音沒有任何關系。舉個例子“愛”的 Unicode 碼點是\u7231“北”是\u5317“城”是\u57CE。默認sort()排序時“北”(0x5317) 排在“城”(0x57CE) 前面“城”又排在“愛”(0x7231) 前面。但按拼音應該是“愛”(ai) → “北”(bei) → “城”(cheng)順序完全亂套。這背后涉及的機制是 ICUInternational Components for Unicode?，F(xiàn)代瀏覽器和 Node.js 在實現(xiàn)localeCompare和Intl.Collator時會調(diào)用 ICU 內(nèi)置的語言排序規(guī)則。中文排序規(guī)則里面包含了拼音字典數(shù)據(jù)所以它知道“愛”對應的拼音是“ai”“北”是“bei”。但前提是你要把這個語言環(huán)境參數(shù)正確傳進去。1.2 方案選型原生 API 還是拼音庫我梳理了當前主流的三種方案先做個對比方案實現(xiàn)方式優(yōu)點缺點A字符串調(diào)用localeCompare(b, zh-Hans-CN)原生支持無需依賴性能好多音字受限于 ICU 字典個別字不準BIntl.Collator實例化比較器可復用實例適合高頻比較參數(shù)更精細底層邏輯跟 A 一樣多音字問題同樣存在C引入 pinyin / pinyin-pro 拼音庫能拿到完整拼音和首字母控制力最強增加包體積大列表場景需要做緩存我的習慣是如果只是排序優(yōu)先用方案 A 或 B如果需要拿拼音做更多事情搜索、分組、首字母索引再引入拼音庫。為了一個排序功能就甩一個幾百 KB 的庫進去完全不劃算。另外說一句別迷信哪種方案一定“最正確”。我見過有人只憑一兩個用例就斷定localeCompare不行結(jié)果換成拼音庫又得處理各種多音字詞庫反而更麻煩。選型的核心依據(jù)是業(yè)務場景對準確率的要求以及你手里已有的依賴。2. localeCompare 與 Intl.Collator 核心用法2.1 基礎語法和參數(shù)拆解localeCompare的完整語法是string.localeCompare(compareString, locales, options)三個參數(shù)里locales和options都可以省略。但做中文拼音排序時這兩個參數(shù)恰恰是關鍵。先看locales。要傳中文語言標簽const arr [重慶, 北京, 上海, 深圳, 廣州]; arr.sort((a, b) a.localeCompare(b, zh-Hans-CN)); console.log(arr); // 期望結(jié)果[北京, 重慶, 廣州, 上海, 深圳]這里有幾個常見的語言標簽寫法zh、zh-CN、zh-Hans-CN、zh-Hant-TW。在大多數(shù)現(xiàn)代瀏覽器里簡體中文的排序結(jié)果差異不大。但有一個細節(jié)我測試過如果你不傳或只傳zh某些瀏覽器的默認 ICU 數(shù)據(jù)可能拿不到簡體中文的排序規(guī)則結(jié)果退化到按 Unicode 碼點排序。所以穩(wěn)妥的做法是寫zh-Hans-CN這種完整的 BCP 47 標簽。再來看options。這個參數(shù)控制比較精度最常用的幾個選項const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base, numeric: true, ignorePunctuation: true });sensitivity: base忽略大小寫、重音符號和聲調(diào)只區(qū)分字母本身。做拼音排序時最推薦這個。numeric: true排序時把數(shù)字按數(shù)值比較而不是字符串字典序。這樣“第2章”會排在“第10章”前面。ignorePunctuation: true忽略標點符號對排序的影響。2.2 兩種 API 的差異與性能對比localeCompare和Intl.Collator底層是同一套 ICU 排序規(guī)則功能上等價。區(qū)別在于使用方式// 不推薦每次比較都走一遍內(nèi)部邏輯 arr.sort((a, b) a.localeCompare(b, zh-Hans-CN)); // 推薦先創(chuàng)建比較器復用 compare 方法 const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); arr.sort(collator.compare);Intl.Collator實例化一次后compare方法可以直接復用。對于反復排序的場景比如用戶點了好幾次表頭切換升降序性能差距會很明顯。我實際測過一萬條數(shù)據(jù)的數(shù)組復用 Collator 比每次調(diào)用localeCompare快約 30%~40%。另外提醒一句collator.compare是一個函數(shù)引用直接傳給sort沒問題。但要注意箭頭函數(shù)的寫法會讓this綁定失效這個在比較器里通常不影響因為compare不依賴this。2.3 關于排序穩(wěn)定性ES2019 之后Array.prototype.sort被要求是穩(wěn)定排序。也就是說如果兩個元素的比較結(jié)果相同它們原來的相對順序會被保留。這一點對中文排序挺重要。比如你有一個列表先按創(chuàng)建時間排好再按拼音排序。當拼音相同時穩(wěn)定排序能保留之前的時間順序用戶看到的就是“拼音相同再按時間排”的效果。老一些的瀏覽器比如 IE11 和某些舊版 WebView不是穩(wěn)定排序如果你需要兼容它們就得自己加一個序號字段作為第二比較鍵。users.sort((a, b) { const result collator.compare(a.name, b.name); if (result ! 0) return result; return a.createTime - b.createTime; // 第二排序鍵 });3. 完整項目實現(xiàn)從數(shù)組到通訊錄分組3.1 純字符串數(shù)組排序最基礎的場景直接把城市列表按拼音排序const cities [重慶, 北京, 上海, 深圳, 廣州, 成都, 杭州]; const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); cities.sort(collator.compare); console.log(cities); // [北京, 成都, 重慶, 廣州, 杭州, 上海, 深圳]注意觀察“重慶”的位置它在“成都”之后、“廣州”之前說明“重”確實被識別為 chong而不是 zhong。這是大多數(shù)現(xiàn)代瀏覽器中 ICU 字典的表現(xiàn)但我在某些舊版 Android WebView 里測過“重慶”會被排到 Z 組去。如果你的用戶群里有大量舊設備最好用我后面說的“拼音庫自定義詞典”兜底方案。3.2 對象數(shù)組按拼音字段排序?qū)嶋H業(yè)務中更多是對象數(shù)組比如人員列表按姓名排序const users [ { name: 張三, age: 28 }, { name: 李四, age: 32 }, { name: 王五, age: 25 }, { name: 陳六, age: 30 } ]; const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); users.sort((a, b) collator.compare(a.name, b.name)); // 按 陳、李、王、張 的順序排列這里有一個必須處理的情況name字段可能為空或undefined。不處理的話collator.compare會直接拋異常。我的習慣是先做空值判斷users.sort((a, b) { const nameA a.name ?? ; const nameB b.name ?? ; return collator.compare(nameA, nameB); });空字符串的排序位置在最前面符合大多數(shù)業(yè)務直覺。3.3 通訊錄首字母分組實戰(zhàn)“按首字母分組”和“按拼音排序”是一對孿生需求通訊錄、城市索引都用得到。這里需要拿到每個漢字的首字母原生Intl.Collator只能比較排序不能輸出拼音字符串所以我會引入 pinyin-pro 這個庫。先安裝npm install pinyin-pro然后取首字母并分組import { pinyin } from pinyin-pro; function getInitial(char) { const result pinyin(char, { pattern: first, toneType: none }); return result.charAt(0).toUpperCase(); } const contacts [ { name: 張三 }, { name: 李四 }, { name: 王五 }, { name: 陳六 }, { name: Ann } ]; // 先按拼音排序 const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); contacts.sort((a, b) collator.compare(a.name, b.name)); // 再按首字母分組 const groups {}; contacts.forEach(item { const initial getInitial(item.name.charAt(0)); if (!groups[initial]) { groups[initial] []; } groups[initial].push(item); }); console.log(groups); // A: [{ name: Ann }] // C: [{ name: 陳六 }] // L: [{ name: 李四 }] // W: [{ name: 王五 }] // Z: [{ name: 張三 }]關于拼音庫選型我對比過pinyin、pinyin-pro、tiny-pinyin這幾個pinyin-pro體積小gzip 后 8KB 左右多音字識別率高支持自定義詞典推薦。pinyin老牌庫功能全但體積偏大。tiny-pinyin極簡但不支持多音字適合只取首字母的場景。3.4 點擊表頭排序的表格實現(xiàn)管理后臺的表格基本都有“點擊表頭排序”的功能放在這里一起講因為核心邏輯完全一樣只是多了方向切換和狀態(tài)管理。function sortTableByField(tableData, field, order) { const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base }); return [...tableData].sort((a, b) { const result collator.compare(String(a[field] ?? ), String(b[field] ?? )); return order asc ? result : -result; }); }這里有一個經(jīng)驗之談排序前一定要先復制數(shù)組用[...tableData]而不是直接tableData.sort(...)。尤其在 React/Vue 這種數(shù)據(jù)驅(qū)動視圖的框架里直接修改原數(shù)組會導致你在setState或reactive里很難追蹤數(shù)據(jù)變化容易觸發(fā)重復渲染、列表 key 錯亂等一堆問題。很多搜索詞里出現(xiàn)的“點擊表頭排序”“字符串排序”“js 忽略大小寫”都是在這個場景下衍生的。實際項目里涉及中英文混排時sensitivity: base就能同時解決忽略大小寫的問題。4. 多音字、生僻字與邊界場景處理4.1 多音字為什么不能完美解決這是漢字拼音排序最讓人頭疼的部分。同一個字在不同詞語里讀音可能完全不同而 ICU 內(nèi)置的排序規(guī)則只能根據(jù)字本身的常見讀音來排。舉幾個典型例子“重慶”的“重”讀 chóng但默認字典可能按 zhòng 處理“廈門”的“廈”讀 xià但默認可能按 shà 處理“單”作姓氏讀 shàn作形容詞讀 dān“解”作姓氏讀 xiè我實測過 Chrome 最新版“重慶”能正確排到 C 組但“單田芳”“解曉東”這類人名的姓氏讀音就很不穩(wěn)定。這不是 JS 的 bug而是 ICU 字典覆蓋不了所有上下文。4.2 拼音庫兜底與自定義詞典如果你的業(yè)務對多音字準確率有硬性要求我推薦一個三層策略自定義詞典優(yōu)先把業(yè)務里高頻出現(xiàn)的特殊讀音詞條維護成一個 JSON排序前先查這個詞條。拼音庫兜底沒命中詞典的詞用 pinyin-pro 這種帶多音字詞庫的庫生成拼音。原生 API 保底如果用戶環(huán)境不支持 ES Module 或者不想引庫退回到localeCompare。pinyin-pro 支持傳入自定義拼音import { pinyin } from pinyin-pro; const customDict { 重慶: chong qing, 廈門: xia men, 單田芳: shan tian fang, 解曉東: xie xiao dong }; function sortWithDict(arr) { return arr.sort((a, b) { const pa customDict[a] || pinyin(a, { toneType: none, type: array }).join( ); const pb customDict[b] || pinyin(b, { toneType: none, type: array }).join( ); return pa.localeCompare(pb, zh-Hans-CN, { sensitivity: base }); }); }這個方法的好處是詞典只管特殊詞常見詞交給拼音庫整體可控性很強。壞處也很明顯需要一個維護成本。我會把這個詞典放到后端接口里下發(fā)這樣前端不用發(fā)版就能更新讀音數(shù)據(jù)。4.3 中英文混合、數(shù)字開頭與特殊字符中文排序場景里經(jīng)?；熘⑽?、數(shù)字和標點這類邊角情況需要單獨處理。我的經(jīng)驗是先按“首字符類型”分桶再做組內(nèi)排序。比如約定排序規(guī)則為數(shù)字 英文 中文或者反過來。不然的話“123”和“abc”和“張三”混在一起比較很容易出現(xiàn)預期之外的順序。function mixedSort(arr) { const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base, numeric: true }); return [...arr].sort((a, b) { const typeA getType(a); const typeB getType(b); if (typeA ! typeB) return typeA - typeB; return collator.compare(a, b); }); } function getType(str) { const first str.charAt(0); if (/[0-9]/.test(first)) return 0; if (/[a-zA-Z]/.test(first)) return 1; return 2; }這個“先分桶再排序”的思路比在比較函數(shù)里寫一堆正則判斷要清晰得多也好維護。5. 常見問題與排查技巧實錄5.1 大小寫和音調(diào)干擾排序現(xiàn)象apple和Apple被排到完全不同的位置或者“媽”(mā) 和“馬”(mǎ) 被當成不同字處理。原因localeCompare默認的分級是variant會區(qū)分大小寫、重音和音調(diào)。拼音排序的預期通常不關心聲調(diào)。解決設置sensitivity: base。const collator new Intl.Collator(zh-Hans-CN, { sensitivity: base });這個選項我在多個項目里都是固定配置省心。5.2 不同瀏覽器與 Node 版本的結(jié)果差異最讓人無語的坑同一份代碼Chrome 里排序正常Firefox 里順序不一樣Node 里又是第三種結(jié)果。根源是 ICU 數(shù)據(jù)版本不一致。瀏覽器各自內(nèi)置的 ICU 完整度不同尤其老版本 Safari 和某些國產(chǎn)瀏覽器中文排序支持非常薄弱。Node.js 環(huán)境更明顯。Node 14 之前的默認構建只帶small-icu只包含很少的語言數(shù)據(jù)中文排序大概率直接用不了。我踩過這個坑之后排查步驟固定如下直接在 Node 里跑一次北京.localeCompare(上海, zh-Hans-CN)看結(jié)果是不是負數(shù)。如果是 0相等說明 ICU 數(shù)據(jù)不完整考慮升級 Node或者用full-icu包補全數(shù)據(jù)。如果業(yè)務必須跨端保持順序一致最穩(wěn)妥的辦法是服務端返回拼音字段前端只做字段字符串比較。5.3 大列表性能優(yōu)化一萬條數(shù)據(jù)的數(shù)組排序Intl.Collator大概幾十毫秒看起來不慢。但如果每條數(shù)據(jù)里還要做拼音轉(zhuǎn)換比如為了首字母分組性能就會明顯劣化。優(yōu)化方案是緩存。拼音轉(zhuǎn)換的結(jié)果是確定性的同一個字永遠轉(zhuǎn)出同一個拼音。用Map做一層緩存const pinyinCache new Map(); function getPinyinWithCache(text) { if (pinyinCache.has(text)) { return pinyinCache.get(text); } const result pinyin(text, { toneType: none, type: array }).join( ); pinyinCache.set(text, result); return result; }實務里這個緩存效果立竿見影。通訊錄這種重復姓氏很多的場景緩存命中率能到 95% 以上排序耗時基本可以忽略。5.4 排序結(jié)果和接口對不上有一種很常見的場景前端自己排了一版后端接口也有一個排序字段兩邊結(jié)果不一致產(chǎn)品經(jīng)理來問。我遇到過幾次最后定位到的原因都是前端的排序規(guī)則和后端的排序規(guī)則不是同一套。比如后端用的是 MySQL 的ORDER BY CONVERT(name USING gbk)按 GBK 編碼順序排而前端用的是拼音兩邊的“字典序”概念根本不一樣。這種事靠前端調(diào)代碼是調(diào)不齊的。正確做法是排序規(guī)則以一端為準。要么后端把所有數(shù)據(jù)排好再返回前端只做展示要么后端把每個字段的拼音串作為獨立字段返回前端直接用String.prototype.localeCompare做普通字符串比較。兩邊都嚴格走同一條拼音數(shù)據(jù)鏈路才能保證一致。6. 寫在最后方向比代碼更重要做前端這幾年我最大的感受是像“漢字按拼音排序”這種需求真正難的往往不是那一行sort代碼而是你選哪條路走下去。如果你只做一次簡單的城市列表排序原生Intl.Collator一行就夠。如果你做的是通訊錄、企業(yè)組織架構、后臺表格這種對準確率和性能都有要求的場景別猶豫直接上“拼音庫自定義詞典緩存”的組合。要記住一個原則方案復雜度永遠跟著業(yè)務需求走不要為了技術炫耀引入復雜度也不要為了省事而犧牲準確率。最后分享一個排查排序問題的小工具。我會在控制臺里跑這樣一段代碼快速看當前運行環(huán)境對中文排序的支持情況console.log(北京.localeCompare(上海, zh-Hans-CN)); // 期望輸出負數(shù)因為 bei shang如果輸出 0 或正數(shù)說明環(huán)境有問題這個簡單的驗證步驟能幫你省掉后面排查環(huán)境的非常多時間。排序看起來是小事但踩過坑的人都知道它有時候比寫一個業(yè)務模塊還磨人。希望這篇文章能讓你少走幾步彎路。