最直接验证当前生效时区的方式是调用 date_default_timezone_get()，它返回 php 实际使用的时区名称（如 asia/shanghai），而非配置文件中的值或系统默认值；若返回空字符串，说明未设置且无 fallback；需结合 date('t e p') 和 datetime 构造行为综合验证是否真正生效。
用 date_default_timezone_get() 看当前生效时区
这是最直接的验证方式，它返回 PHP 实际使用的时区名称（如 Asia/Shanghai），不是配置文件里写的值，也不是系统默认值。
常见错误是只改了 php.ini 却没重启 Web 服务或 CLI 进程，导致 date_default_timezone_get() 仍返回 UTC 或空字符串（PHP 8.1+ 会报 Warning: Unknown time zone ""）。
- 在 Web 环境中，需重启 Apache/Nginx + PHP-FPM；CLI 下改完
php.ini要新开终端或重运行命令 - 如果返回空字符串，说明未设置且 PHP 没 fallback 到系统时区（某些容器环境或精简版 PHP 会这样）
- 注意：该函数不校验时区名是否合法，
date_default_timezone_set('Foo/Bar')也能“成功”，但后续date()会出错
用 date('T e P') 检查实际时间输出是否符合预期
光有时区名还不够，得看时间计算是否正确。比如设为 Asia/Shanghai，但输出仍是 UTC 时间，说明时区没真正生效，或被代码里某处 date_default_timezone_set() 覆盖了。
date('T e P') 分别输出时区缩写（CST）、时区标识符（Asia/Shanghai）、带偏移的完整格式（+08:00）。三者一致才可信。
立即学习“PHP免费学习笔记（深入）”；
- 若
e是Asia/Shanghai但T是UTC，说明底层时区数据缺失（如 Alpine Linux 容器缺tzdata包） - 若
P显示+00:00，大概率是时区名拼错（如写成Asia/ShangHai）或系统时区数据库太旧 - 避免只用
date('Y-m-d H:i:s')——它不显式暴露时区，容易误判
检查 DateTime 构造行为是否受控
很多业务逻辑依赖 new DateTime() 的默认行为，它是否真按你设的时区解析字符串，才是关键。
例如：new DateTime('2024-01-01') 在 Asia/Shanghai 下应等价于 2024-01-01 00:00:00 +08:00，而不是 UTC 时间戳再转本地显示。
- 测试方法：创建一个无时区的
DateTime对象，然后调用$dt->getTimezone()->getName()，看是否匹配预期 - 若返回
UTC，说明构造时没继承默认时区，可能因date_default_timezone_set()被覆盖，或用了new DateTime('now', new DateTimeZone('UTC'))这类显式指定 - 注意：PHP 8.2+ 对未指定时区的
DateTime构造更严格，会触发Warning，而旧版本可能静默 fallback
排查 phpinfo() 和 ini_get('date.timezone') 的差异
phpinfo() 显示的是配置项来源（主配置、.htaccess、ini_set），而 ini_get('date.timezone') 只读运行时值，两者不一致就说明有动态覆盖。
尤其在 Laravel、WordPress 等框架中，常在启动阶段调用 date_default_timezone_set()，此时 ini_get() 可能为空，但 date_default_timezone_get() 已被改写。
- 优先信
date_default_timezone_get()，它是最终生效值；ini_get()只反映配置文件或ini_set()是否起效 - 容器环境下，
phpinfo()里Date模块显示的 “Default timezone” 若为UTC，但date_default_timezone_get()返回其他值，说明代码里强制设置了 - 不要依赖
/etc/localtime符号链接判断——PHP 不读这个，它用的是内部时区数据库（zoneinfo）
date_default_timezone_set() 调用就能让前面所有配置失效，而错误往往延迟到日志时间、定时任务或跨时区用户请求时才暴露。 
