setlocale()改变的是什么
setlocale()设置当前进程的区域信息。这个设置影响字符串比较、大小写转换、数字格式化、日期时间格式化、货币显示等一系列依赖区域的行为。它不是对某个变量赋值，而是修改了一个全局状态——调用之后，所有后续的区域敏感操作都会受其影响。
<?php
// 代码号学习PHP：区域设置影响字符串大小写
setlocale(LC_ALL, 'tr_TR.UTF-8'); // 土耳其语
echo strtolower('I'); // 输出 ı（无点小写 i），而非 i
setlocale(LC_ALL, 'en_US.UTF-8');
echo strtolower('I'); // 输出 i
土耳其语的“I”转小写得到“ı”而非“i”，这是setlocale()影响strtolower()行为的直接体现。
分类常量
setlocale()的第一个参数指定受影响的分类：
| 常量 | 影响范围 | 关联函数 |
|---|---|---|
LC_ALL |
以下所有分类 | 全部 |
LC_COLLATE |
字符串比较 | strcoll() |
LC_CTYPE |
字符分类与转换 | strtoupper()、strtolower() |
LC_MONETARY |
货币格式化 | localeconv()、money_format() |
LC_NUMERIC |
数字格式化 | localeconv()、printf()的%f |
LC_TIME |
日期时间格式化 | strftime() |
LC_MESSAGES |
系统消息格式 | gettext() |
传入LC_ALL会同时设置所有分类。使用具体分类常量可以只影响特定行为，减少副作用。
查询当前设置：NULL与0的差异
第二个参数传NULL或"0"时，函数不改变设置，只返回当前值。
<?php
// 代码号学习PHP：查询当前区域设置
$current = setlocale(LC_ALL, 0);
echo $current;
// 可能输出：LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;...
社区反馈指出一个平台差异：在部分SUSELinux系统上，setlocale(LC_ALL,NULL)会重置为服务器设置，而setlocale(LC_ALL,0)才返回当前值。手册声称两者等价，但实际行为因平台而异。
PHP版本差异
| 版本 | 变化 |
|---|---|
| PHP4.0.4 | 第一个参数接受字符串形式的分类名 |
| PHP4.0.5 | 第一个参数改为必须使用常量，不再接受字符串 |
| PHP4.3.0 | 第二个参数支持数组形式，用于尝试多个locale |
| PHP8.5 | 第二个参数类型收紧为严格字符串（strictstring） |
PHP4.0.5的这次改动有明确的迁移影响。HordeIMP项目在升级时发现@setlocale('LC_ALL',$language)不再工作，必须改为@setlocale(LC_ALL,$language)。
PHP8.5的类型收紧意味着传入非字符串值（如整数或null）可能触发TypeError，与之前版本的宽松转换行为不同。
平台差异与locale名称格式
这是使用setlocale()时最实际的困难来源。locale名称的格式因操作系统而异：
Windows：使用语言_国家.代码页格式，如English_UnitedStates.1252、Italian_Italy.1250。Windows的NLSAPI不支持需要超过两个字节的代码页（如UTF-7、UTF-8）。
Linux/Unix：使用语言_国家.编码格式，如de_DE.UTF-8、cs_CZ.utf8。locale需要系统安装。使用locale-gencs_CZ.utf8可添加新locale（可能需要sudo权限）。
编码指定：在Linux上，如果locale名称不包含编码信息，setlocale(LC_TIME,'de_DE')返回的日期可能包含非UTF-8字符，在UTF-8页面中显示为乱码。必须使用de_DE.UTF-8才能得到正确输出。
<?php
// 代码号学习PHP：locale 名称的平台适配
$locales = [
'en_US.UTF-8', // Linux
'en_US.utf8', // 部分 Unix 变体
'English_United States.1252', // Windows
'en_US', // 简写形式
];
$set = false;
foreach ($locales as $locale) {
if (setlocale(LC_ALL, $locale) !== false) {
$set = true;
break;
}
}
传入数组时，setlocale()会依次尝试每个值直到成功。这是跨平台兼容的常用策略。
线程安全问题
setlocale()修改的是进程级全局状态。在PHP-FPM或Apache的线程化MPM模式下，多个请求可能共享同一进程，区域设置的变更会影响其他请求。
PHPBug#65230记录了PHP5.5中setlocale(LC_ALL,...)随机失效的问题。报告者指出：“同一段代码在不同浏览器标签页中可能得到不同结果。”维护者的回应是：“localeconv()不是线程安全的，使用它配合_configthreadlocale()可能导致不可预测的结果。”
这个问题的根本原因是locale的线程局部存储机制与PHP的请求隔离模型不匹配。解决方案是避免在共享进程中依赖setlocale()的持久效果。
性能开销
setlocale()本身的开销通常很小，它只是设置一个内部状态。但有两个场景需要注意：
频繁调用：如果在循环中反复调用setlocale()，每次都会触发系统调用和locale数据的重新加载。Xdebug的Bug#1096记录了一个极端案例：Magento2处理LESS文件时，setlocale()被调用了超过800万次，请求耗时接近一分钟。
替代方案：将locale设置一次并在整个请求生命周期内复用，避免在循环中调用。
常见误区速查
| 误区 | 实际行为 |
|---|---|
setlocale(LC_ALL,NULL)和setlocale(LC_ALL,0)等价 |
部分Linux发行版上NULL会重置设置 |
| 所有系统上的locale名称相同 | Windows和Unix使用不同的命名格式 |
设置LC_TIME后strftime()一定生效 |
部分Windows系统需要同时设置LC_CTYPE，且已设置的分类不会重新应用 |
setlocale()返回false时会抛出异常 |
返回false，不抛异常，必须显式检查返回值 |
| locale设置对当前请求立即可见 | 线程化环境下可能受其他请求干扰 |
与intl扩展的职责对比
PHP的intl扩展提供了更可靠的区域敏感操作替代方案：
| 能力 | setlocale()方式 | intl方式 |
|---|---|---|
| 数字格式化 | LC_NUMERIC+printf() |
NumberFormatter |
| 日期格式化 | LC_TIME+strftime() |
IntlDateFormatter |
| 字符串比较 | LC_COLLATE+strcoll() |
Collator |
| 货币格式化 | LC_MONETARY+money_format() |
NumberFormatter |
| 线程安全 | 否 | 是 |
| 跨平台一致性 | 低 | 高 |
setlocale()依赖操作系统提供的locale数据。同一个de_DE在Windows、glibc、musllibc上的行为可能不同。PHPBug#78056记录了nl_BElocale的货币格式在glibc中的错误，最终被确认为上游libc的bug。
intl扩展使用ICU库的数据，不依赖系统locale，行为在所有平台上一致。Bug#65230的维护者建议：“你真的应该依赖intl的NumberFormatter，它更好且更可移植。”
现在框架中的实践
Laravel、Symfony等框架不直接暴露setlocale()。Symfony的Translator组件使用Locale类管理语言，日期和数字格式化通过intl完成。Laravel的Lang类同样不依赖系统locale。
需要区域感知格式化时，现在PHP代码优先选择intl：
<?php
// 代码号学习PHP：intl 替代方案
$formatter = new NumberFormatter('de_DE', NumberFormatter::CURRENCY);
echo $formatter->formatCurrency(1234.56, 'EUR');
// 输出：1.234,56 €
$dateFormatter = new IntlDateFormatter(
'de_DE',
IntlDateFormatter::FULL,
IntlDateFormatter::NONE
);
echo $dateFormatter->format(new DateTime());
延伸练习
练习一：编写一个跨平台的locale设置函数，接受语言代码（如de、fr），尝试Linux、Windows、BSD等不同命名格式，返回成功设置的locale名称。
练习二：创建一个测试脚本，在同一个PHP-FPM进程中先后设置两种不同的LC_NUMERIC，观察printf("%.2f",1234.56)的输出是否一致，验证线程安全问题。
练习三：对比setlocale(LC_TIME,'de_DE.UTF-8')+strftime()与IntlDateFormatter在格式化德语月份名称时的输出差异，观察编码处理的不同。
延伸阅读
PHP官方手册：setlocale()
https://www.php.net/manual/en/function.setlocale.php
官方函数文档，包含分类常量列表、locale名称格式说明、数组回退机制，以及大量社区注释中关于平台差异和编码问题的讨论。
PHPBug#65230：setting locale randomly broken
https://bugs.php.net/bug.php?id=65230
PHP5.5中setlocale随机失效的报告。维护者确认localeconv非线程安全，并建议使用intl扩展作为替代。
PHPBug#28746：money_forma tbroke in php4.3.6
https://bugs.php.net/bug.php?id=28746
记录了money_format()与setlocale(LC_MONETARY)配合使用时在不同PHP版本和服务器上的行为变化，说明locale功能对底层libc的依赖。
PHPBug#78056：Wrong currency format fornl_BE withmoney_format
https://bugs.php.net/bug.php?id=78056
荷兰语比利时locale的货币格式错误报告，最终确认为glibc的上游bug，展示了locale数据质量对应用行为的影响。
XdebugBug#1096：Breakpoint bottleneck inlarge codebase
https://bugs.xdebug.org/view.php?id=1096
Xdebug调试器在大型代码库中反复调用setlocale()导致性能问题的记录，Magento2场景下单次请求调用超过800万次。
TYPO3CoreTask#107270：Run unit tests with PHP8.5
https://forge.typo3.org/issues/107270
PHP8.5将setlocale()第二个参数类型收紧为严格字符串的适配记录，框架层需要调整测试用例以应对类型检查变化。
