PHP默认时区为UTC，须显式设置date_default_timezone_set('Asia/Shanghai')或php.ini中配置date.timezone，否则date()、DateTime等均按UTC处理，易致8小时偏差及跨时区逻辑错误。
PHP默认时区是UTC，不是服务器本地时间
很多PHP脚本在开发机上跑得正常，一上生产环境就发现时间差8小时（或其它偏移），根本原因是date_default_timezone_get()返回UTC，而你没显式设置。PHP 5.4+ 默认不读取系统/etc/timezone或TZ环境变量，也不会自动继承Apache/Nginx的时区配置。
必须在代码最开始（或php.ini中）调用date_default_timezone_set()，否则所有date()、strtotime()、DateTime构造都按UTC解析和格式化。
- 推荐写法：
date_default_timezone_set('Asia/Shanghai')（不要用PRC，已废弃） - 避免写
date_default_timezone_set('GMT+8')——这不是合法时区标识，会触发Warning: date_default_timezone_set(): Unknown or bad timezone -
php.ini里设date.timezone = Asia/Shanghai比代码里设更可靠，尤其对CLI脚本
DateTime对象构造时没指定时区，等于隐式用默认时区
new DateTime('2024-01-01')和new DateTime('2024-01-01', new DateTimeZone('Asia/Shanghai'))行为完全不同：前者把字符串当作“默认时区下的本地时间”解析；后者明确按东八区解释。一旦后续做setTimezone()转换，结果就可能出错。
典型陷阱：从MySQL查出datetime字段（无时区信息），直接new DateTime($row['created_at'])，再转UTC存入日志——如果默认时区是UTC，那原始值就被当成UTC处理了，实际却是数据库所在服务器的本地时间。
立即学习“PHP免费学习笔记（深入）”；
- 始终显式传入
DateTimeZone对象，哪怕只是new DateTimeZone(date_default_timezone_get()) - 从数据库读时间时，优先用
DateTimeImmutable+ 显式时区，避免意外修改 - 用
$dt->format('c')输出ISO 8601格式时，注意它带时区偏移（如+08:00），而Y-m-d H:i:s不带——后者容易掩盖时区混淆
MySQL连接层与时区不同步导致时间写入错乱
PHP的mysqli或PDO连接建立后，默认使用MySQL服务端全局时区（通常是SYSTEM，即系统本地时间）。但PHP自己用的是另一套时区逻辑，两者不联动。结果就是：INSERT INTO t (ts) VALUES (NOW())写入的是MySQL服务器本地时间，而PHP用date('Y-m-d H:i:s')生成的值却是PHP默认时区的时间，混用就会错位。
解决办法不是“统一成一个时区”，而是明确分层：存储用UTC，显示/输入按需转换。
- 连接建立后立即执行
SET time_zone = "+00:00"（mysqli）或PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+00:00'"（PDO） - 确保MySQL配置
default-time-zone='+00:00'，避免新连接回退到SYSTEM - 禁止在SQL里用
CURDATE()、NOW()等函数生成业务时间——全部由PHP用(new DateTime('now', new DateTimeZone('UTC')))->format('Y-m-d H:i:s')生成
strtotime()对模糊时间字符串的解析依赖默认时区，且不可靠
strtotime('today')、strtotime('next Monday')这类相对时间，在不同时区下计算出的Unix timestamp完全不同。更危险的是，strtotime('2024-03-31')这种看似绝对的日期，若默认时区启用了夏令时（如Europe/Berlin），还可能因DST切换导致解析偏差1小时。
这类函数本质是面向“本地时间”的文本解析器，不适合跨时区系统。
- 改用
DateTime类：例如(new DateTime('today', new DateTimeZone('Asia/Shanghai')))->setTimezone(new DateTimeZone('UTC')) - 绝对时间字符串（如API传来的
2024-03-31T12:00:00+08:00）优先用DateTime::createFromFormat()或构造函数直接解析，别喂给strtotime() - CI/CD部署时检查
date_default_timezone_get()输出，别只信phpinfo()页面——CLI和Web SAPI可能不同
时区问题最难调试的点在于：它不报错，只悄悄差几个小时，而且只在跨地域部署、日志比对、定时任务触发等场景才暴露。最保险的做法是——所有时间值在进入PHP边界时立刻打上明确时区标签，之后不再依赖“默认”。
