PHP默认时区为UTC而非服务器本地时区，排查需优先调用date_default_timezone_get()和date()验证实际生效值，框架配置、php.ini修改（如date.timezone = "Asia/Shanghai"）、系统时区同步及Docker tzdata配置均须一致。
PHP 默认时区不是服务器本地时区，而是 UTC —— 这是绝大多数线上环境出时间偏差的根本原因。
确认 PHP 当前生效的时区设置
别只看 php.ini 里写的 date.timezone，它可能被运行时覆盖。最可靠的方式是直接查脚本中实际生效的值：
- 用
date_default_timezone_get()输出当前默认时区（注意：它不报错，哪怕没设也会返回一个值，比如UTC） - 配合
date('Y-m-d H:i:s e')看具体时间 + 时区标识，比单纯读配置更直观 - 如果用的是 Laravel、ThinkPHP 等框架，优先检查框架自身的时区配置（如
config/app.php中的'timezone'），它通常会调用date_default_timezone_set()覆盖 php.ini
修改 php.ini 中的 date.timezone 是最稳妥的全局方案
找到你实际在用的 php.ini（用 php --ini 或 phpinfo() 确认路径），编辑后必须重启 PHP-FPM 或 Apache：
- 写法必须是标准时区名，例如：
date.timezone = "Asia/Shanghai"（不能写GMT+8或PRC） - Linux 服务器上，
Asia/Shanghai和系统时区/etc/localtime指向一致时，strtotime()、DateTime等行为才稳定 - 若用 Docker，确保基础镜像已安装 tzdata，并在容器启动时挂载或执行
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
date_default_timezone_set() 在脚本中临时覆盖的风险
这个函数只影响当前请求生命周期，但容易引发隐蔽问题：
立即学习“PHP免费学习笔记（深入）”；
- 如果多个模块分别调用它（比如 A 库设了
"UTC"，B 库又设成"Asia/Shanghai"），结果不可预测 - CLI 模式下常被忽略 ——
php artisan schedule:run或队列 worker 可能跑在不同配置下，导致日志时间、数据库写入时间错乱 - 错误示例：
date_default_timezone_set($_SERVER['TZ'] ?? 'UTC')—— 用户可控输入直接进时区设置，会触发警告甚至失败（PHP 8.1+ 严格校验）
验证服务器与 PHP 时区是否真正同步
光看 date 命令和 date() 函数输出一样还不够：
- 执行
timedatectl status（systemd 系统）或cat /etc/timezone，确认系统时区是Asia/Shanghai而非UTC - 在 PHP 中运行：
echo date('c') . ' | ' . exec('date +"%c"');—— 两行输出应完全一致（包括时区缩写，如+0800） - 特别注意 cron 定时任务：它的环境变量可能不加载 shell profile，
date命令显示对，但 PHP 脚本仍按 UTC 解析时间戳
时区问题最难调试的地方在于：它不报错、不中断流程，只悄悄让日志时间偏移、缓存过期提前、定时任务漏跑——务必在部署新环境时就把 date.timezone 和系统时区对齐，而不是等订单时间对不上才去查。
