Laravel 的 timezone 配置仅影响 PHP 原生时间函数，不自动同步 Eloquent 或数据库行为；Eloquent 默认以 UTC 存储时间，数据库 CURRENT_TIMESTAMP 依赖 MySQL 时区，Carbon 的 tz() 返回新实例而 setTimezone() 修改原实例，需统一时区策略并分层配置。
App 配置的 timezone 只影响 PHP 原生时间函数，不自动同步 Eloquent 或数据库行为
很多人改了 config/app.php 里的 'timezone' => 'Asia/Shanghai'，就以为所有时间都“自动对齐”了，结果 created_at 还是 UTC、Carbon::now() 在命令行里却显示本地时间——这是因为 Laravel 的时区配置只设置 PHP 的默认时区（即影响 date()、strtotime() 等），但 Eloquent 写入数据库时默认仍用 UTC（尤其配合 MySQL 的 TIMESTAMP 类型时），而数据库连接层本身可能另有设置。
实操建议：
- 确认数据库服务器时区：执行
SELECT @@global.time_zone, @@session.time_zone;，MySQL 默认常为SYSTEM（即系统时区），但 Docker 或云数据库可能不同 - Eloquent 模型写入前强制转时区：
$model->created_at = now()->tz('Asia/Shanghai');不推荐，易遗漏；更稳妥的是统一用 UTC 存储 + 应用层转换展示 - 若坚持本地时区存储，需在数据库连接配置中加
options => [PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+08:00'"]（注意：仅对 MySQL 有效，且必须确保连接字符集兼容）
Carbon 实例的 tz() 和 setTimezone() 区别很关键
tz() 返回新实例，原实例不变；setTimezone() 是原地修改。新手常写 $time->tz('Asia/Shanghai'); echo $time;，发现没变——因为没接返回值。
常见错误现象：
-
Carbon::parse('2024-01-01')->tz('Asia/Shanghai')正确，得到北京时间午夜 -
Carbon::parse('2024-01-01')->setTimezone('Asia/Shanghai')也正确，但会修改原对象 -
$c = Carbon::now(); $c->tz('Europe/London'); var_dump($c->isoFormat('HH:mm'));→ 仍是本地时间，因忽略返回值
使用场景提示：API 返回 JSON 时，通常用 toArray() 或 jsonSerialize()，它们默认输出 ISO8601 字符串（含时区偏移），所以务必确保 Carbon 实例已调用 tz() 或构造时指定时区，否则前端拿到的可能是服务端本地时区字符串，而非用户期望时区。
数据库迁移中用 useCurrent() / useCurrentOnUpdate() 会受 MySQL 全局时区影响
写迁移时习惯加 $table->timestamps()，它底层生成 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP。但这个 CURRENT_TIMESTAMP 是由 MySQL 解析执行的，走的是 MySQL 自己的时区，不是 PHP 或 Laravel 的 timezone 配置。
参数差异与风险：
- 如果 MySQL 服务器时区是
+00:00，而你 PHP 设的是Asia/Shanghai，那created_at存的是 UTC 时间，但Carbon::parse($model->created_at)默认按 PHP 时区解析，会多加 8 小时 -
useCurrentOnUpdate()同理，更新时间由 MySQL 触发，不受 Laravel 控制 - 解决方案不是改 MySQL 时区（运维成本高），而是统一约定：数据库存 UTC，应用层用
Carbon::createFromFormat('Y-m-d H:i:s', $value, 'UTC')->tz('Asia/Shanghai')展示
队列任务里的时间容易“静默错位”，尤其跨时区部署时
比如一个定时任务在凌晨 2 点触发，本地开发环境没问题，上线后却发现延迟 8 小时执行——大概率是队列 worker 进程启动时读取的系统时区和 Web 请求进程不一致，或者 Supervisor 配置没透传 TZ 环境变量。
实操建议：
- 检查队列 worker 启动方式：
php artisan queue:work是否在screen或supervisord中运行？后者需显式配置environment=TZ="Asia/Shanghai" - 避免在任务中直接用
now()判断逻辑，改用传递时间戳：SomeJob::dispatch(now()->addHours(1))，让调度时刻固化 - Docker 部署时，基础镜像（如
php:8.2-cli）默认无时区，必须加ENV TZ=Asia/Shanghai && ln -sf /usr/share/zoneinfo/$TZ /etc/localtime
时区问题最麻烦的从来不是“设不设”，而是“在哪一层设、对谁生效、谁在读它”。PHP、MySQL、OS、Docker、前端 JS —— 每一层都可能有自己的时区上下文，漏掉一层，时间就悄悄偏移。
