php date() 比系统时间慢8小时是因默认时区为utc，需设为asia/shanghai；mysql时区需单独配置；框架中timezone配置可能被覆盖；strtotime(‘now’)返回时间戳不受时区影响，new datetime()则依赖php时区。
PHP date() 返回的时间比系统时间慢8小时
这是最典型的时区未设置表现，尤其在服务器位于 UTC 时区（如 docker 官方 PHP 镜像、部分云主机）而开发者预期是东八区（Asia/Shanghai）时。PHP 默认使用 UTC，date('Y-m-d H:i:s') 就会比北京时间少 8 小时。
- 先确认当前生效的时区：
echo date_default_timezone_get(); - 不要依赖
/etc/timezone或系统date命令输出——PHP 不自动读取系统时区 - 临时修复：在脚本开头加
date_default_timezone_set('Asia/Shanghai'); - 永久修复优先改
php.ini中的date.timezone = Asia/Shanghai，重启 PHP 服务（如php-fpm或 apache）
MySQL 插入时间与 PHP time() 不一致
当 PHP 用 date('Y-m-d H:i:s') 拼 SQL 插入时间，而 MySQL 的 datetime 字段显示早 8 小时，大概率是两边时区没对齐。MySQL 有自己的时区设置，和 PHP 是独立的。
- 查 MySQL 当前时区：
select @@global.time_zone, @@session.time_zone; - 若返回
SYSTEM，则 MySQL 使用系统时区；但 PHP 并不共享该值 - 稳妥做法：PHP 统一用
date('Y-m-d H:i:s')生成东八区时间字符串，并确保 MySQL 也设为Asia/Shanghai（修改my.cnf的default-time-zone = '+08:00'或'Asia/Shanghai'） - 避免混用：
time()返回的是 unix 时间戳（无时区），但转成字符串时依赖 PHP 时区设置
laravel / thinkphp 等框架中 now() 仍显示 UTC 时间
框架通常封装了时间处理，但底层仍走 PHP 的时区配置。如果已设 date.timezone 却无效，可能是被框架或环境变量覆盖。
- Laravel：检查
config/app.php中的'timezone' => 'Asia/Shanghai'，这个值会调用date_default_timezone_set() - ThinkPHP：查看
app.php配置里的default_timezone，或确认是否在启动文件中被重复调用date_default_timezone_set() - Docker 环境常见坑：PHP 镜像里
php.ini没改，但又在entrypoint里 export 了PHP_INI_DIR，导致自定义 ini 未加载 - 验证是否生效：在框架路由/控制器里直接执行
var_dump(date_default_timezone_get(), date('Y-m-d H:i:s'));
strtotime('now') 和 new DateTime() 结果不一致
表面上都是“当前时间”，但行为可能不同——strtotime() 返回时间戳（秒数），DateTime 对象默认按 PHP 时区解释字符串，且可显式指定时区。
立即学习“PHP免费学习笔记（深入）”；
-
strtotime('now')总是返回当前 Unix 时间戳（与服务器硬件时间一致，不受 PHP 时区影响） -
new DateTime()等价于new DateTime('now', new DateTimeZone(date_default_timezone_get()))，所以它输出的字符串受时区控制 - 安全写法：
new DateTime('now', new DateTimeZone('Asia/Shanghai'))显式绑定时区，不依赖全局设置 - 跨时区转换场景下，优先用
DateTime+setTimezone()，而非反复调用strtotime()
时区问题不是“设一个参数就完事”，关键在于 PHP、MySQL、运行环境三者时区逻辑要各自清晰，且彼此对齐。最容易被忽略的是：Docker 容器内 PHP 时区配置未生效，或框架配置被中间件/自动加载覆盖。每次遇到时间偏差，先单独验证 date_default_timezone_get() 和 date('Y-m-d H:i:s') 输出，再查数据库时区，比猜更省时间。