必须存储用UTC、展示按用户时区转换，而非仅改config/app.php的timezone；Carbon实例化需显式指定源时区，入库前调utc()，展示时用tz($user->timezone)。
直接改 config/app.php 的 'timezone' 不解决全球用户问题——它只设全局默认时区，所有用户看到的还是同一个时间。真要支持多时区，必须「存储用 UTC，展示按用户时区转」，且不能依赖框架默认配置兜底。
Carbon 实例化时别被 config/app.php 里的 timezone 带偏
很多人以为改了 'timezone' => 'Asia/Shanghai' 就万事大吉，结果发现用户在纽约看到的时间还是北京时间。这是因为：
-
Carbon::now()、now()、new Carbon()确实读这个配置，但仅影响「无明确时区上下文」的解析 -
Carbon::parse('2024-01-01 12:00')会按该配置当成上海时间解析，而不是用户所在时区 - 数据库字段如
created_at默认走模型的$dates或casts，若没显式处理时区，存进去的就是应用时区时间，不是 UTC
正确做法是：入库前强制转 UTC，例如 now()->utc()；查出来再按需转本地，例如 $post->created_at->tz($user->timezone)。
laravel-timezone 包的 convertToLocal 为什么有时不生效
Timezone::convertToLocal($time) 看似方便，但容易踩三个坑：
- 它内部调用的是
Carbon::createFromFormat()+ 用户timezone字段，如果users.timezone是空或非法值（比如'GMT+8'），转换会 fallback 到应用默认时区 - 传入的
$time必须是 Carbon 实例，不能是字符串或 MySQL 时间戳字符串；否则先被Carbon::parse()解析，又绕回 config/app.php 的时区 - Blade 指令
@displayDate()本质也是调这个方法，但它不抛异常，出错就静默退化成原始时间格式
验证方式：打印 $user->timezone 和 get_class($post->created_at)，确保两者都合法。
用户输入时间怎么安全转成 UTC 存库
用户提交一个带时区含义的时间（比如表单里选的“今天下午 3 点”），你不能直接塞进模型：
- 前端没传时区信息？那就必须靠后端补——用
$request->ip()查torann/geoip得到大致时区，再用Carbon::createFromFormat('Y-m-d H:i', $input, $detectedTz)->utc() - 前端传了时区（如
Intl.DateTimeFormat().resolvedOptions().timeZone）？优先信它，用Carbon::parse($input, $clientTz)->utc() - 千万别写
Carbon::createFromFormat('Y-m-d H:i', $input)->utc()——没指定源时区，createFromFormat会按应用默认时区解释字符串，结果偏移 8 小时是常态
示例：Carbon::parse('2026-05-07 15:00', 'America/New_York')->utc()->toDateTimeString() 输出 '2026-05-07 19:00:00'（UTC 时间），这才是安全入库值。
数据库和 PHP 时区要分清，别混着配
MySQL 的 time_zone 设置和 Laravel 的 app.timezone 是两回事：
- MySQL 设为
+00:00或UTC，能让NOW()、CURRENT_TIMESTAMP返回 UTC，配合 Laravel 的useCurrent()迁移更稳 - PHP 层（php.ini 的
date.timezone）建议保持UTC，避免 CLI 命令、队列任务等场景因时区不一致导致时间错乱 - 不要在
config/database.php里加'timezone' => '+08:00'来“修正”显示——这会让 PDO 把所有时间字段自动转成东八区再吐给 PHP，和 Carbon 的 UTC 转换逻辑打架
真正需要干预的只有两点：入库前用 Carbon 转 UTC，展示前用 Carbon 转用户时区。其他地方越少动时区配置，越不容易翻车。
