真正稳住时区需同步配置PHP环境、数据库连接和业务逻辑三层：config/app.php仅影响无参时间函数；MySQL需显式设time_zone；任务调度须用timezone()锁定；入库存UTC，展示时再转目标时区。
直接改 config/app.php 的 'timezone' 不解决实际问题——它只影响 now()、Carbon::now() 这类无上下文的调用，对数据库存取、API 输出、任务调度、用户时间展示几乎无效。真要稳住时区，得从三层下手：PHP 环境、数据库连接、业务逻辑层。
config/app.php 的 'timezone' 到底管什么
它只控制：date()、strtotime()、now()、Carbon::now()、new Carbon() 这些“没给时区参数”的调用。其他地方它基本不插手：
- Eloquent 写入
created_at时，用的是当前 PHP 时区值，但 MySQL 的TIMESTAMP字段还会被自己的time_zone覆盖 -
Carbon::parse('2026-09-26')会按这个配置解析字符串——如果你本意是解析用户在东京选的时间，结果却当成上海时间处理了 - API 返回 JSON 时，
toArray()输出的 ISO 字符串时区偏移，取决于 Carbon 实例自身的时区，不是config/app.php的值
MySQL 连接必须显式设 time_zone
Laravel 不会自动给 PDO 连接发 SET time_zone。哪怕你把 config/app.php 和系统时区都设成 Asia/Shanghai，迁移里 $table->timestamps() 生成的 CURRENT_TIMESTAMP 仍可能走 MySQL 全局 time_zone（常为 SYSTEM）。
解决方法是在 config/database.php 的 MySQL 配置里加：
'options' => [
PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+08:00'",
],
或者更稳妥地用命名时区（需 MySQL 支持）：
PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = 'Asia/Shanghai'",
别依赖 mysql.time_zone 表未加载就写 Asia/Shanghai，会报错。
任务调度 timezone() 必须显式调用
即使应用和服务器时区都对齐了，Laravel 12 的调度器仍可能跑偏——因为底层 Cron 守护进程只认系统本地时间，而 Laravel 调度器解析 dailyAt('09:00') 时默认按 config/app.php 解析，两者若不一致就错位。
最可靠写法是每个任务都锁死时区：
$schedule->command('reports:generate')->dailyAt('08:30')->timezone('Asia/Shanghai');
这样无论部署到 UTC 服务器还是开发机，该任务都严格按东八区执行。多时区 SaaS 还可动态传入：->timezone($user->timezone)，前提是 $user->timezone 是合法 IANA 标识符（如 America/Chicago），不是 GMT-5 这种模糊写法。
入库前转 UTC，查出来再转目标时区
数据库字段（如 published_at）建议统一存 UTC，否则多时区用户查数据会乱。常见错误是：
- 模型
casts写成'published_at' => 'datetime:Y-m-d'——取值时自动变成字符串，失去 Carbon 实例能力 - 入库前没调
now()->utc()，导致存进去的是应用时区时间 - 查出来直接
$post->published_at->format('Y-m-d H:i')，没先->tz($user->timezone)
正确姿势：
// 入库
$post->published_at = now()->utc();
// 查询后展示
$post->published_at->tz('Asia/Tokyo')->format('Y-m-d H:i');
注意：->tz() 返回新实例，->setTimezone() 是原地修改——写 $time->tz('UTC'); 却不接返回值，等于白干。
真正麻烦的不是设哪个值，而是三处（PHP、MySQL、业务逻辑）必须同步且语义一致：存的是 UTC 时间点，展示时才按需“换皮肤”。任何一处偷懒用 config/app.php 一把梭，后面排查时间错乱问题会花掉你两倍时间。
