为什么JavaScript的toLocaleString会忽略系统和浏览器的en_GB地区设置？

关于问题的核心解答 #

1. 这大概率不是你的手动配置错误

这是Chromium系浏览器的已知默认locale判断逻辑导致的问题，它的默认locale优先级判断和普通用户的认知存在差异：除了你看到的浏览器显示语言、系统地区设置外，它还会参考浏览器安装时的初始地区、系统的「区域格式」设置（注意不是系统显示语言）、部分第三方打包的Chromium发行版的自定义编译参数，如果你开启了Windows系统的「使用Unicode UTF-8提供全球语言支持」试验性功能，也会干扰浏览器的locale识别。

2. 开发者工具覆盖功能的作用原理

Sensors面板的地区覆盖功能会直接修改JavaScript运行时的两个核心配置，所以能直接生效：

• 强制修改navigator.language的值，同时覆盖navigator.languages数组的首位元素为你指定的en_GB
• 直接修改ECMA-402国际化API的内部默认locale：不带参数调用toLocaleString()时，本质是执行Intl.DateTimeFormat(undefined, { dateStyle: "short", timeStyle: "medium" }).format(当前日期)，这里传入的undefined会读取JS运行时的默认locale，开发者工具的覆盖操作就是直接修改了这个内部默认值，不会受浏览器本身的识别逻辑影响。

3. 浏览器没有自动读取默认语言设置的原因

Chromium的locale fallback逻辑非常严格：如果它从系统API读取到的地区标识无法和内置的国际化资源包完全匹配，就会直接降级到默认的en_US，而不是就近匹配同语言的其他地区版本。常见的触发场景包括系统区域格式设置和显示语言地区不匹配、浏览器没有安装对应en_GB的国际化资源包、系统返回的地区标识存在自定义后缀无法被识别。

内容的提问来源于stack exchange，提问作者dklymenk