php 时区设置错误最直接的表现是 date()、strtotime()、DateTime 等函数返回的时间和你预期不一致，或者抛出 Warning: date(): It is not safe to rely on the system's timezone settings 警告 —— 这说明 PHP 根本没拿到有效时区，正 fallback 到系统默认（通常不准）。
为什么 date_default_timezone_set() 必须在所有时间操作前调用
这个函数不是“设一次就全局生效”的配置项，而是运行时状态。一旦脚本启动后没设，后续任何时间函数都可能触发警告或错乱；而且它不能在函数内部、条件分支里“补救”——比如你在某个 if 分支里才调用，前面已经执行过的 date() 就已经错了。
- 必须放在脚本最顶部（或至少在第一个时间函数调用前），常见位置是入口文件（如
index.php）开头、框架的初始化逻辑最前端 - 不要依赖
php.ini里的date.timezone设置：docker 容器、共享主机、CLI 和 Web SAPI 的 php.ini 可能不同，容易漏配 - 值必须是 IANA 时区名（如
"Asia/Shanghai"），不能写"GMT+8"或"CST"—— 后者是模糊缩写，PHP 不识别
DateTime 构造时不显式传时区，就等于用当前默认时区
DateTime 对象创建时如果不指定时区，会直接继承 date_default_timezone_set() 设定的值。很多人以为 new DateTime('2024-01-01') 是“无时区的原始字符串”，其实不是：它立刻被解释成默认时区下的本地时间，再转为 UTC 存储。一旦默认时区错，这个对象从诞生起就偏了。
- 安全做法是显式传
DateTimeZone：new DateTime('2024-01-01', new DateTimeZone('Asia/Shanghai')) - 如果处理的是用户输入的“纯日期”（如表单提交的
2024-01-01），且业务逻辑明确属于某地时间，务必绑定该地时区，别让它“猜” - 注意：
new DateTime('@1704067200')（unix timestamp）不受默认时区影响，它始终代表 UTC 时间点 —— 这是少数能绕过时区陷阱的写法
CLI 和 Web 请求用了不同 php.ini，date.timezone 配置容易漏
PHP CLI 模式和 apache/nginx 的 PHP SAPI 通常加载不同的 php.ini 文件。你在网页里测好了，但用 php artisan schedule:run 或 php cron.php 执行定时任务时突然时间错乱，大概率是 CLI 的 php.ini 里没配 date.timezone，也没在脚本里手动 date_default_timezone_set()。
立即学习“PHP免费学习笔记（深入）”；
- 检查 CLI 配置：运行
php -i | grep "Loaded Configuration File"，再确认该文件里有date.timezone = "Asia/Shanghai" - 更可靠的做法是：在所有可独立执行的 PHP 脚本（尤其是命令行脚本、crontab 调用的脚本）开头强制设一次，不依赖配置文件
- 不要用
getenv('TZ')或系统TZ环境变量自动推断 —— PHP 不读这个，且环境变量可能为空或非法
真正麻烦的不是设不对，而是设得“看起来对”：比如开发机设了 "Asia/Shanghai"，测试通过；上线后服务器系统时区是 UTC，而运维只改了系统时区，没动 PHP 配置，结果所有时间函数悄悄按 UTC 解释本地时间字符串 —— 这种错不会报错，只会慢 8 小时，还很难复现。