ThinkPHP 的 timezone 配置仅通过 date_default_timezone_set() 影响后续原生日期函数，若在框架初始化前调用 date()/strtotime() 等，则仍按 PHP 默认时区（如 UTC）执行，导致时间差8小时；Db 查询中 DATETIME 字段自动转为带时区的 DateTime 对象，其显示受 PHP 时区影响；模型 autoWriteTimestamp 写入的是 PHP 当前时区的本地时间，非 UTC；所有原生日期函数均绕过框架封装，必须确保时区设置早于首次调用。
ThinkPHP 默认已设好时区，但你手动调用 date() 或 strtotime() 时，依然会按 PHP 全局默认时区走——不是框架“没管”，而是你绕过了它的封装。
为什么 config/app.php 里设了 'timezone'，date() 还是差 8 小时？
ThinkPHP 在启动阶段确实会调用 date_default_timezone_set()，但它只影响后续未执行过的日期函数。一旦你在框架初始化前（比如在入口文件顶部、或某个自定义引导脚本里）提前用了 date()、strtotime() 或 new DateTime()，PHP 就已“锁定”默认时区（通常是 UTC），之后框架的设置就无效了。
- 常见错误现象：
Warning: date(): It is not safe to rely on the system's timezone settings仍出现；date('Y-m-d H:i:s')输出的是 UTC 时间 - 检查方式：在控制器任意 action 开头加
var_dump(date_default_timezone_get());，确认值是否为Asia/Shanghai - 根本原因：CLI 环境下 ThinkPHP 的启动流程和 Web SAPI 不同，
php think run或队列任务中容易漏设时区 - 安全做法：不在任何业务逻辑前碰原生日期函数；如必须用，确保
date_default_timezone_set('Asia/Shanghai')出现在thinkphp/base.php加载之前（极少见），或改用框架提供的封装
think\facade\Db 查询出来的 created_at 是字符串还是时间戳？
取决于数据库字段类型和 ThinkPHP 版本。5.1+ 默认对 TIMESTAMP 和 DATETIME 字段自动转成 DateTime 对象（带时区），但这个对象的时区由当前 PHP 默认时区决定，不是数据库 session 时区。
- 如果你的 MySQL
time_zone是+00:00，而 PHP 时区是Asia/Shanghai，那么$user->created_at->format('Y-m-d H:i:s')会自动 +8 小时（即把 UTC 存储值转成本地显示） - 如果数据库存的是
INT时间戳，ThinkPHP 不会自动转对象，返回纯整数，此时直接date('Y-m-d', $user['created_at'])才有效——但前提是 PHP 时区已设对 - 隐患点：用
whereTime('created_at', '>=', '2025-01-01')这类方法时，ThinkPHP 内部会调用strtotime()，仍受全局时区影响；建议统一传时间戳或DateTime实例
ThinkPHP 的 date() 辅助函数和原生 date() 有什么区别？
没有区别。ThinkPHP 的 think\helper\Str::date()（或早期版本的 think\facade\Env::date()）只是对原生 date() 的简单封装，不接管时区逻辑，也不做任何时区转换。
立即学习“PHP免费学习笔记（深入）”；
- 它不会读取
config/app.php的timezone配置，也不会自动绑定DateTimeZone - 调用
date('Y-m-d', $ts)和think\helper\Str::date('Y-m-d', $ts)行为完全一致 - 真正起作用的是框架在
think\App::initialize()中调用的date_default_timezone_set($this->app['config']->get('app.timezone'))—— 但仅限于原生函数生效范围 - 替代方案：用
think\facade\Date::format($ts, 'Y-m-d H:i:s')（6.x+），它内部使用DateTime构造并显式传入时区，更可控
在模型里用 autoWriteTimestamp 时，created_at 存的是哪个时区的时间？
存的是 PHP 当前默认时区下的本地时间，不是 UTC，也不是数据库 session 时区。也就是说，如果 PHP 时区是 Asia/Shanghai，那写入的就是北京时间字符串（如 '2026-05-23 13:11:00'）；如果没设时区，就是 UTC。
- 风险点：当数据库字段是
TIMESTAMP类型时，MySQL 会把该字符串按当前 session 时区转成 UTC 存——如果 PHP 时区是Asia/Shanghai，而 MySQL session 时区是+00:00，就会被二次转换，导致存错 - 最稳做法：数据库字段用
DATETIME（无自动时区转换），并在模型中强制指定写入格式：'created_at' => date('Y-m-d H:i:s')，避免依赖自动填充逻辑 - 进阶控制：重写模型的
createTime()方法，返回(new DateTime())->setTimezone(new DateTimeZone('Asia/Shanghai'))->format('Y-m-d H:i:s')
最常被忽略的一点：ThinkPHP 的时区配置只保底，不兜底。它能防止你完全忘记设时区，但挡不住你在任意位置插入一句裸 strtotime('tomorrow')——那一刻，时区上下文就脱离框架掌控了。
