PHP 8.5.5时区转换不准确的根本原因是配置与代码协同失效：date_default_timezone_set()未在入口首行调用、DateTime构造漏传时区、CLI/Web加载不同php.ini、MySQL未同步时区，导致同一代码在不同环境输出偏差时间。
PHP 8.5.5 的时区转换不准确，根本原因不是版本 Bug，而是时区配置未真正生效或代码层未显式隔离时区上下文——date_default_timezone_set() 没在正确时机调用、DateTime 构造漏传 DateTimeZone、或 CLI/Web 环境加载了不同 php.ini，都会导致同一段代码在不同场景下输出偏差时间。
date_default_timezone_set() 调用太晚或被覆盖
一旦执行过 date()、strtotime() 或 new DateTime()，PHP 就会锁定默认时区（或触发警告），此时再调用 date_default_timezone_set('Asia/Shanghai') 已无效——它不会修正之前已解析的时间值。
- 常见错误：把设置放在中间件、模型初始化、或
if ($env === 'prod')分支里，测试环境不触发，上线后全错 8 小时 - 实操建议：固定放在入口文件（如
public/index.php）第一行非注释 PHP 代码处，并立刻校验：var_dump(date_default_timezone_get());确保输出是"Asia/Shanghai" - 不要依赖框架配置类加载时机——
ThinkPHP的default_timezone不会自动调用date_default_timezone_set()，仍需手动设
DateTime 构造没传时区参数，隐式绑定默认时区
new DateTime('2026-06-25') 和 new DateTime('2026-06-25', new DateTimeZone('Asia/Shanghai')) 行为完全不同：前者把字符串当作“当前默认时区下的本地时间”解析；后者明确按东八区解释。若默认时区是 UTC，原始字符串就被当成 UTC 时间处理了。
- 典型陷阱：从 MySQL 查出
datetime字段（无时区信息），直接new DateTime($row['created_at'])，再转 UTC 存日志——结果原始值被误当 UTC 解析，实际却是数据库服务器本地时间 - 实操建议：始终显式传入
DateTimeZone对象，哪怕只是new DateTimeZone(date_default_timezone_get()) - 优先用
DateTimeImmutable，避免意外修改对象状态
CLI 和 Web 环境用了不同 php.ini，date.timezone 不一致
你用 php -i | grep "date.timezone" 看到的值，未必等于 Nginx/Apache 下 PHP 实际用的值——CLI 和 Web SAPI 可能加载完全不同的 php.ini 文件。
立即学习“PHP免费学习笔记（深入）”；
- 排查方法：Web 环境下输出
phpinfo()，搜date.timezone，看 “Loaded Configuration File” 路径；CLI 下执行php --ini，对比路径是否一致 - 常见坑：Docker 镜像（如
php:8.5-apache）默认没配date.timezone，且 CLI 和 FPM 容器可能用不同配置目录 - 实操建议：两个环境都配，或统一用
PHP_INI_SCAN_DIR指向同一配置目录；别只改 Web 的php.ini，忘了php -v用的其实是另一份
MySQL 时区没同步，PHP 显示对了但数据库存错了
PHP 改了时区，MySQL 还按自己的节奏走：PHP 显示北京时间正常，但 NOW() 写入的仍是 UTC 时间，或查询结果被 MySQL 按 SYSTEM 时区自动转换。
- 验证命令：
SELECT @@global.time_zone, @@session.time_zone;，确认不是SYSTEM（它可能指向 UTC） - 推荐方案：在
my.cnf中设置default-time-zone = '+08:00'，然后重启 MySQL；不建议每次连接后执行SET time_zone = '+08:00'，连接池复用时容易失效 - 更彻底的解法：存储层优先用
int类型存time()，天然规避所有时区格式化问题
最易被忽略的是：即使 date_default_timezone_get() 返回 "Asia/Shanghai"，也不能保证所有时间逻辑都正确——DateTime 对象、MySQL 连接、crontab 触发基准、甚至 Docker 容器内 /etc/localtime 是否真实指向 zoneinfo/Asia/Shanghai，都得单独验证。时区问题从来不是单点配置，而是一整条链路的协同。
