共同形态：new Intl.X(locales, options)
九个 Intl 子 API 的结构高度一致：用 locale（给谁看）和 options（想要什么形式）构造一个可复用的格式化器对象，再反复调它的 .format() / .select() / .compare() /
.of()。先理解这个共同骨架，其余各页只是更换 options。
1 · 骨架：构造一次，多次复用
构造器接收的第一参数 locales 可以是一个字符串或一个数组（按优先级排，挑第一个支持的）；不传则用浏览器默认 locale。第二参数 options 是个普通对象，各 API 认的字段不同。返回的格式化器是无状态、可缓存的——同样的 (locale, options)
别在循环里反复 new。
2 · locale 串怎么读：BCP-47 分段
locale 是一串用 - 连接的标签(BCP-47)。点下面任意一段看含义：
-u- 是 Unicode 扩展：把本地化偏好直接写进 locale 串，免去 options。常见键：nu（数字系统，如 hanidec 汉字数字、arab 阿拉伯数字）、ca（历法 chinese/buddhist）、co（排序
pinyin/stroke）、hc（h12/h23 小时制）。例如 zh-u-nu-hanidec 让数字显示成「一二三」。
3 · 同一个骨架，九个 API
选一个 locale 和 API，看「同一套写法」如何套到每个子 API 上，并看它实际跑出什么：
4 · locale 协商：你要的不一定拿得到
你请求一串 locale，运行时按某种算法挑一个真正支持的，挑不到就一路 fallback（zh-Hant-HK → zh-Hant → … → 默认）。用哪种算法由 option localeMatcher 决定（lookup / best fit，见下）。resolvedOptions().locale
告诉你最终选中谁,supportedLocalesOf() 告诉你一串里哪些被支持:
localeMatcher 是上面每个构造器（及 supportedLocalesOf）都认的 option，决定用哪种协商算法：'lookup' 是 BCP-47(RFC 4647)定义的严格算法，只逐段截断回退(zh-Hant-HK → zh-Hant → zh);'best fit'（默认）是实现自定义的「最佳匹配」，允许挑一个 lookup 不会选、但体验更接近的 locale（如把 de-CH 当 de、zh-TW 当 zh-Hant 处理）。日常无需指定，保留默认 best fit 即可。
常见陷阱：new Intl.X('xx-YY') 几乎从不抛错——请求的 locale 不可用时会静默 fallback 到默认 locale。想知道「到底用了哪个 locale / 哪些 option 生效」，以 resolvedOptions() 为准，不要靠假设。