多语言时间显示本质是区域和时区协同问题，需用IntlDateFormatter替代strftime()，显式设置locale与时区，并在框架中动态同步用户上下文。
PHP里时间戳本身没有语言属性，所有“多语言时间显示”问题，本质都是格式化阶段的区域（locale）和时区（timezone）协同问题。直接用date()或strftime()输出，永远只能得到服务器本地设置的结果，跟用户语言无关。
setlocale() + strftime() 组合失效的典型原因
很多人以为只要调用setlocale(LC_TIME, 'de_DE.UTF-8')再用strftime('%A, %B %d', $ts)就能显示德语星期和月份——但常遇到返回空字符串、英文、或乱码。
- 系统根本没安装
de_DE.UTF-8：运行locale -a | grep de_DE确认存在；Alpine 需apk add --no-cache locale-all，Debian/Ubuntu 需sudo locale-gen de_DE.UTF-8 -
setlocale()返回false却没检查：必须判断返回值，否则后续strftime()仍在旧 locale 下执行 - PHP 进程未重启：修改系统 locale 后，PHP-FPM 或 Apache 必须重载，CLI 模式下也要新开终端
- UTF-8 编码未声明：
header('Content-Type: text/html; charset=utf-8')缺失时，德语变音字母（如Montag）可能显示为
IntlDateFormatter 是更可靠的选择
相比strftime()，IntlDateFormatter不依赖系统 locale，只依赖 ICU 数据库（PHP 编译时已内置），支持更多语言且行为稳定。
- 构造时传入真实
locale字符串（如'fr_FR'），不用带.UTF-8后缀 - 必须显式指定时区：
new IntlDateFormatter('fr_FR', ..., ..., new DateTimeZone('Europe/Paris'))，否则默认用date_default_timezone_get() - 格式类型用常量：
IntlDateFormatter::MEDIUM比手工写'EEEE, MMMM d, yyyy'更安全，避免 ICU 版本差异导致解析失败 - 注意
format()返回false的情况：输入DateTimeInterface对象无效、时区不可识别、或 ICU 初始化失败（可加if (!$formatter) { throw new RuntimeException(...); }）
Yii2/Laravel 等框架中 formatter 的陷阱
框架封装了IntlDateFormatter，但容易忽略两个关键点：时区继承和 locale 动态切换。
立即学习“PHP免费学习笔记（深入）”；
- Yii2 的
formatter组件默认使用Yii::$app->timeZone，但这个值在应用启动时就固化了；如果用户时区存在 session 差异（如后台管理员在纽约、前端用户在东京），必须手动覆盖：Yii::$app->formatter->timeZone = 'Asia/Tokyo' - Laravel 的
Carbon::setLocale()只影响diffForHumans()等相对时间，不影响formatLocalized()——后者仍依赖setlocale(LC_TIME)，所以仍需系统 locale 支持 - 框架中切换语言时，
formatter不会自动重设 locale；需主动调$formatter->locale = 'ja_JP'（Yii2）或App::setLocale('ja')（Laravel）并确保 formatter 实例被刷新
真正难的不是写对一行格式化代码，而是保证每次请求中：时区来自用户上下文而非服务器配置，locale 来自会话/请求头而非硬编码，且两者在格式化前已同步生效。漏掉任意一环，时间就会在某个小语种用户面前突然“失语”。
