thinkphp 默认时区由 php 的 date.timezone 决定，必须在 php.ini 中设置为 iana 标准名（如 asia/shanghai），重启服务后生效；修改 thinkphp 配置无效，临时 set 不可靠。
ThinkPHP 默认时区由 PHP 底层决定，不单独配置
ThinkPHP 本身没有独立的「默认时区」配置项。它完全依赖 PHP 运行时的时区设置——也就是说，date()、strtotime()、DateTime 等函数返回什么时间，ThinkPHP 的 date() 辅助函数、日志时间、模型自动写入的 create_time 等就用什么时间。改 ThinkPHP 配置文件（如 app.php 或 timezone.php）不会生效。
必须在 PHP 层统一设置 date.timezone
所有 ThinkPHP 项目都绕不开这个前提：确保 PHP 的 date.timezone 已正确设定。否则你会看到警告：It is not safe to rely on the system's timezone settings，且数据库写入时间、缓存过期、定时任务都可能错乱。
- 优先修改
php.ini：找到 ThinkPHP 实际运行所用的 php.ini（CLI 和 Web 可能不同，用php --ini或phpinfo()确认），取消注释并设为：date.timezone = "Asia/Shanghai" - 重启对应服务：Web 场景需重启
php-fpm或 Web 服务器；CLI 场景（如命令行执行php think queue:work）需确保 CLI 的 php.ini 也已同步修改 - 别用
GMT+8或PRC：PHP 不识别这些缩写，只接受 IANA 标准名，如Asia/Shanghai、Asia/Chongqing（二者等效）、UTC
ThinkPHP 中临时覆盖时区要慎用
虽然你可以在控制器开头写 date_default_timezone_set('Asia/Shanghai')，但 ThinkPHP 的核心生命周期（如中间件、事件、模型事件）可能已在该语句之前触发，导致部分时间仍按旧时区生成。更稳妥的做法是：
- 在入口文件
public/index.php最顶部（<?php后第一行）就调用date_default_timezone_set()，确保整个请求生命周期从一开始就锁定时区 - 避免在模型或服务类里反复调用该函数——它不是线程安全的，在并发请求下可能污染其他请求的时区上下文
- 真正需要多时区逻辑（如用户本地时间展示），应使用
DateTime显式构造，例如：new DateTime('now', new DateTimeZone('Asia/Tokyo'))
数据库时区也要对齐，否则时间显示仍会错位
ThinkPHP 写入数据库的时间值，如果 MySQL 本身时区是 SYSTEM 且系统设的是 UTC，而 PHP 设的是 Asia/Shanghai，就会出现「PHP 认为是 10:00，MySQL 存成 02:00」的问题。必须检查并保持一致：
- 执行 SQL：
SELECT @@global.time_zone, @@session.time_zone;，确认返回值是+08:00或SYSTEM（且系统时区确实是东八区） - 若 MySQL 是
SYSTEM但系统时区不对，需修改操作系统时区（如 Linux 执行timedatectl set-timezone Asia/Shanghai） - 更推荐方案：MySQL 全局设为
UTC，PHP 也设为UTC，业务层再按需转换展示——这样可规避夏令时、历史时区变更等隐性坑
config('app.timezone') 并非 PHP 时区开关，它只影响少数视图助手（如 date() 模板函数），且默认不存在。别被名字误导。时区问题从来不是框架配置漏了，而是 PHP 环境和数据库两层没对齐。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
