根本原因是PHP时区设置三层冲突：php.ini的date.timezone未正确设为Asia/Shanghai、ThinkPHP的default_timezone仅影响框架内部、MySQL连接时区未同步；三者必须同时对齐，否则date()等函数输出错误。
ThinkPHP 的日期时间显示不一致，根本原因不在框架本身，而在 PHP 运行时的时区设置层级冲突——php.ini、date_default_timezone_set()、数据库连接时区三者没对齐。
php.ini 里 date.timezone 设错，整个应用时间就飘了
这是最常被忽略的底层开关。ThinkPHP 不会主动覆盖它，但所有 date()、strtotime()、Carbon::now()（如果用了）都依赖它。设成空或错值（比如 Asia/Shanghai 拼错成 Asia/ShangHai），就会回退到 UTC，导致页面上显示比本地快/慢 8 小时。
- 检查方法：
phpinfo()页面搜索date.timezone，确认值是Asia/Shanghai（中国大陆）或你实际部署地的合法时区标识符 - 修改位置：不是 ThinkPHP 的
.env或配置文件，而是服务器上的php.ini（CLI 和 FPM 可能是两个文件，都要改） - 改完必须重启 PHP-FPM 或 Apache，仅 reload 不生效
- 若用 Docker，要在
Dockerfile里显式写RUN echo "date.timezone = Asia/Shanghai" >> /usr/local/etc/php/php.ini，别指望镜像默认值
ThinkPHP 自己的时区配置 default_timezone 是个“软开关”
它只影响框架内部日志、缓存键生成、部分模型自动时间戳（如 created_at），但**不改变 PHP 原生时间函数行为**。很多人以为设了这个就万事大吉，结果 date('Y-m-d H:i:s') 还是 UTC 时间。
- 位置：
config/app.php中的'default_timezone' => 'Asia/Shanghai' - 作用范围有限：主要约束
think\helper\Time、日志格式化、Cache键名里的时间戳等 - 和
php.ini冲突时，以php.ini为准；它不能修复date()输出错误 - 如果项目混合用了原生 PHP 函数和 TP 封装，必须两者同步设，不能只靠这一个
MySQL 连接时区没同步，查出来的 datetime 字段就乱套
即使 PHP 层时区全对，MySQL 默认可能用系统时区（比如服务器在美西，MySQL 用 PST），而 PHP 用 Asia/Shanghai，SELECT 出来的 datetime 看似正确，实则已隐式转换过一次，再用 strtotime() 解析就出错。
立即学习“PHP免费学习笔记（深入）”；
- 验证方法：执行
SELECT @@time_zone, @@system_time_zone;，确认返回的是+08:00或Asia/Shanghai - ThinkPHP 配置中加
'params' => ['time_zone' => '+08:00']到数据库配置的params项（PDO DSN 不支持直接写时区，得靠这个） - 更稳妥做法：在
app\common\command\InitCommand或app\common\middleware\CheckEnv中执行Db::execute("SET time_zone = '+08:00'"); - 注意：
timestamp类型字段不受此影响（它存的是 UTC），但datetime是纯字符串存储，完全依赖连接时区
时间戳转本地格式时，别无脑用 date()，优先走 Carbon 或 think\helper\Time
直接调 date('Y-m-d H:i:s', $timestamp) 看似简单，但一旦服务器时区没设对，或代码里某处调了 date_default_timezone_set() 临时改了时区，结果就不可控。ThinkPHP 自带的 think\helper\Time 和 Carbon 都做了封装，更可靠。
- 推荐写法：
Time::parse($timestamp)->format('Y-m-d H:i:s')（自动按default_timezone转） - 如果用了 Carbon：
Carbon::createFromTimestamp($timestamp, config('app.default_timezone'))->format('Y-m-d H:i:s') - 绝对避免：在循环里反复调
date_default_timezone_set()切换时区，PHP 进程级设置，会影响其他请求 - 调试技巧：打印
date_default_timezone_get()和ini_get('date.timezone')对比，看是否一致
真正麻烦的从来不是“怎么设”，而是三个地方（php.ini、TP 配置、MySQL 连接）要同时对齐，且其中任意一个被运维重置、Docker 重建、或新环境漏配，时间就悄悄跑偏——这种问题往往上线后几天才被用户发现，排查时容易只盯代码，忽略底层 PHP 和数据库的耦合态。
