正确排序中文地址需结构化分层+显式拼音配置：new Intl.Collator('zh', {collation: 'pinyin', sensitivity: 'base', numeric: true})，逐级提取省市区街道并分别排序，多音字和繁简需前置标准化。
直接用 Intl.Collator 对整条中文地址字符串排序，结果大概率错乱——「重庆」会排在「北京」前面，「南山区」可能夹在「东城区」中间。真正支撑地址库高频、多级、可维护的检索排序，关键不在“用不用 Collator”，而在于“怎么配 + 怎么分 + 怎么预”。
必须显式启用拼音排序模式
仅写 new Intl.Collator('zh-CN') 是无效的。浏览器默认走 Unicode 排序（UCA），和拼音完全无关。要激活拼音逻辑，必须显式声明：collation: 'pinyin'。这是 ICU 内置规则，Chrome 90+、Edge 90+、Safari 17+ 已稳定支持。
配套参数不能少：
- sensitivity: 'base'：忽略声调与大小写，让「重庆」「重慶」「chongqing」视为等价
- numeric: true：确保「第3街」排在「第12街」之前，避免字符串字典序翻车
- 不要设
caseFirst或alternate，它们会破坏拼音主序列
示例：
const addrCollator = new Intl.Collator('zh', {
collation: 'pinyin',
sensitivity: 'base',
numeric: true
});
地址必须结构化切分后逐级排序
真实地址如「广东省深圳市南山区科技园科发路8号」是混合结构，不能整串丢给 Collator。否则「南山区」和「浦东新区」的排序权重被「广东省」「深圳市」稀释，失去行政层级语义。
正确做法是按省→市→区→街道→门牌号分层提取，并为每级名称字段单独建立拼音排序索引：
- 提取「广东省」「深圳市」「南山区」作为独立字符串，分别用
addrCollator.compare排序 - 街道名（如「科技园科发路」）建议再做一次切分，保留主干词用于排序，冗余修饰词（如「附近」「西侧」）剔除或降权
- 门牌号拆解为「前缀文字 + 数字主体 + 后缀」，数字部分启用
numeric: true即可自然排序，无需转 Number
多音字与繁简混杂需前置标准化
Intl.Collator 的拼音来自 CLDR 数据库，固定采用普通话标准读音，不识别上下文。比如「重庆」永远按 Chóngqìng 排，不会因用户输入 Zhòngqìng 改变。
若业务对读音敏感（如政务系统、地名志），必须预处理：
- 用
pinyin-pro或pinyin4j为每个地址字段生成带音标的sortKey字段 - 对「台」「厦」「行」「堡」等高频多音字，建白名单映射表（如「厦门 → Xiàmén」、「台州 → Tāizhōu」），人工校准后存入数据库
- 繁体/日文汉字混杂时，统一转简体（推荐
zh-convert）再排序；或按场景选用'zh-Hant-TW'等 locale，但需注意其内置读音倾向台湾习惯
多级组合排序需封装 compare 逻辑
地址库常需「先按省份分组，组内再按城市拼音排，城市内再按区名排」。Collator 本身只比两个字符串，无法感知层级字段。因此不能直接 arr.sort(collator.compare)。
应封装多级 compare 函数：
- 先比省级字段（如
a.provincevsb.province） - 省相同时，再比市级字段（
a.cityvsb.city），传入同一addrCollator.compare - 依此类推，街道、门牌号可逐级 fallback，也可在区级后直接用
addrCollator.compare(a.fullStreet, b.fullStreet)
这样既复用 Collator 的高性能拼音能力，又保留结构化语义控制权。
