ThinkPHP模型时区错乱需手动控制：写入前将时间转为UTC字符串，读取后转为本地时区，通过重写setAttr/getAttr方法实现，且数据库连接须设为UTC时区。
ThinkPHP模型读写时区不一致导致时间错乱
默认情况下，ThinkPHP模型写入数据库用本地时区（比如东八区），读出来还是原样，不会自动转成用户所在时区——结果就是存的是2024-05-20 14:00:00，前端显示却是2024-05-20 06:00:00（UTC+0）。这不是Bug，是设计使然：TP没默认做“存储UTC + 读取转本地”这层转换。
真正要解决的不是“怎么让TP变聪明”，而是明确控制两个环节：datetime字段写入前转UTC、读取后转本地。别指望全局开关一键搞定。
- 必须手动在模型中重写
setAttr和getAttr方法，针对具体时间字段（如create_time）拦截处理 - 不要依赖
defaultTimezone配置——它只影响date()等PHP函数，默认不介入模型字段序列化 - 如果用
Carbon，注意toDateTimeString()返回的是带时区的字符串，直接赋值给模型可能触发二次格式化，建议统一用format('Y-m-d H:i:s')
在模型里对create_time做UTC写入+本地读取
这是最常用也最容易出错的场景。关键不是“加个钩子”，而是确保写入数据库的是UTC时间戳字符串，且读出来能按当前请求时区还原。
示例代码片段（以App\Model\User为例）：
立即学习“PHP免费学习笔记（深入）”；
protected function setCreateTimeAttr($value)
{
// 写入前：无论传进来是字符串、时间戳还是Carbon，都转成UTC的Y-m-d H:i:s
return (new \DateTime($value, new \DateTimeZone(date_default_timezone_get())))
->setTimezone(new \DateTimeZone('UTC'))
->format('Y-m-d H:i:s');
}
protected function getCreateTimeAttr($value, $data)
{
// 读取后：把数据库里的UTC时间，转成当前PHP时区（比如Asia/Shanghai）
if (!$value) return null;
return (new \DateTime($value, new \DateTimeZone('UTC')))
->setTimezone(new \DateTimeZone(date_default_timezone_get()))
->format('Y-m-d H:i:s');
}
- 别在
setCreateTimeAttr里用strtotime($value)——它会按当前时区解析，输入"2024-05-20 14:00"可能被当成本地时间再转UTC，造成+8小时偏差 -
getAttr方法第二个参数$data是整行数据，可用于判断是否需要条件转换（比如只有is_admin == 1才转时区） - 如果前端需要ISO 8601格式（含时区偏移），
format('c')比format('Y-m-d H:i:s')更稳妥
使用whereTime查询时，时间条件必须手动转UTC
whereTime('create_time', '>=', '2024-05-20')这类写法，TP不会自动把右边的字符串转UTC——它直接拼进SQL，查的是数据库里存的UTC值。所以你传'2024-05-20'，实际查的是UTC时间'2024-05-20 00:00:00'，相当于本地时间'2024-05-20 08:00:00'之后的数据。
- 正确做法：所有时间条件都先转UTC再传入
whereTime或where - 封装一个辅助方法，比如
utcTime($time)，内部用new \DateTime($time)->setTimezone(new \DateTimeZone('UTC'))->format('Y-m-d H:i:s') - 避免用
today()、now()这种模糊词——它们返回的是PHP本地时间，必须显式转UTC才能安全用于查询
MySQL时区设置会影响原始SQL行为
即使模型层做了完美转换，如果MySQL服务器时区是SYSTEM（常为CST，即UTC+8），而你的连接没指定时区，像NOW()、CURDATE()这类函数仍会返回服务端本地时间，和模型存的UTC对不上。
- 在数据库连接配置里加上
'timezone' => '+00:00'（TP6.0+支持），强制连接使用UTC - 或者执行
SET time_zone = '+00:00'初始化语句，但要注意有些云数据库（如阿里云RDS）禁止该命令 - 验证方式：连上MySQL执行
SELECT NOW(), @@session.time_zone;，确认两者都是UTC时间
模型层时区转换再严密，只要底层数据库时区没对齐，created_at字段用auto_write生成时就可能写错——这个点最容易被跳过。
