需显式配置 intl.collator 的 collation: 'pinyin'、sensitivity: 'base'、numeric: true，并对地址结构化预处理（按省市区分层提取名称字段单独排序），多音字需预生成标准拼音 sortkey，繁简混合地址宜统一转简体再排序。
直接用 Intl.Collator 对中文地址排序，光写 new Intl.Collator('zh-CN') 是不够的——它默认走 Unicode 码点顺序，「重庆」会排在「北京」前面，「南山区」可能乱入「东城区」中间。真正符合拼音语义、支撑地址库高频检索排序的关键，在于精准配置 collation 模式与配套参数，并做好预处理边界。
必须启用拼音排序模式（collation: 'pinyin'）
这是最核心一步。仅靠 locale 无法激活拼音逻辑，必须显式声明：
- collation: 'pinyin'：启用 ICU 内置拼音排序规则（Chrome 90+、Edge 90+、Safari 17+ 已稳定支持）
- sensitivity: 'base'：忽略音调和大小写差异，让「重慶」「重庆」「chongqing」在比较中视为等价
- numeric: true：确保「第3街」排在「第12街」之前，避免字符串字典序错位
- 不要设
caseFirst或alternate，它们会干扰主拼音序列
示例：
const addrCollator = new Intl.Collator('zh-CN', { collation: 'pinyin', sensitivity: 'base', numeric: true });地址字段需结构化预处理再排序
真实地址库常含混合字段（如「广东省深圳市南山区科技园科发路8号」），不能直接对整串排序。应先提取关键排序层级：
- 按行政层级切分：省 → 市 → 区 → 街道 → 门牌号，分别建立索引字段
- 对「市名」「区名」「街道名」等名称字段单独应用拼音排序器（非全地址字符串）
- 门牌号建议拆为「前缀文字 + 数字主体 + 后缀」，数字部分转 Number 或保留字符串但启用
numeric: true
例如排序「北京市朝阳区」「上海市浦东新区」「广州市天河区」，应基于「北京市」「上海市」「广州市」这三个纯地级市名排序，而非原始长串。
应对多音字与方言读音偏差
Intl.Collator 的拼音基于 CLDR 数据，固定采用普通话标准读音，无法动态识别上下文多音字。比如「重庆」恒按 Chóngqìng 排序，不会因用户输入「Zhòngqìng」而改变。
- 若业务强依赖特定读音（如政务系统需按当地习惯读法排序），须前置标注：用 pinyin4j、pinyin-pro 或 OpenCC 等库预生成带音标的标准拼音字段
- 对「台」「厦」「行」等高频多音字，可建白名单映射表，人工校准后存为
sortKey字段 - 避免在运行时反复调用拼音转换，将
sortKey作为索引列持久化，提升检索性能
混合繁简/跨境地址的兼容策略
当地址库含港澳台或海外华人社区数据（如「臺北市」「九龍城」），单一 'zh-CN' 会导致排序断裂：
- 统一转简体再排序（推荐）：用
zh-convert或opencc预处理，保持拼音规则一致 - 按区域分流：大陆地址用
'zh-CN'，台湾地址用'zh-Hant-TW'，二者排序器独立实例，合并结果时注意层级对齐 - 跨语言混合（如中+英地址）：优先使用
'en'locale 并开启numeric: true，汉字部分按 Unicode 名称（如 U+5317）回退，比强行拼音更稳定
