date_default_timezone_set()仅影响当前请求的PHP时间函数，无法解决多时区需求；必须采用UTC存储+用户时区动态渲染方案，统一用DateTime对象处理时区转换，并确保数据库使用TIMESTAMP且server时区设为+00:00。
PHP date_default_timezone_set() 不能全局覆盖多时区需求
设一次时区只影响当前请求的全局时间函数，比如 date()、strtotime()，但对数据库连接、日志写入、缓存键生成等环节毫无作用。国际化站点里用户分布在东京、纽约、巴黎，硬塞一个 date_default_timezone_set('Asia/Shanghai') 就等于默认所有用户都按北京时间看时间——订单创建时间、活动倒计时、邮件发送时间全乱套。
真正要支持多时区，得把“时区”当成用户属性来管理，而不是 PHP 运行环境配置。
- 用户登录/注册时通过浏览器
Intl.DateTimeFormat().resolvedOptions().timeZone上报时区，或由 IP + 地理库（如 GeoIP2）辅助推测，存进数据库字段user.timezone（值如'America/New_York'） - 关键时间字段（如
created_at）在数据库统一用 UTC 存储（MySQL 设为TIMESTAMP类型，并确认 MySQL server 时区是+00:00） - 展示前再根据用户时区做转换，不是靠
date_default_timezone_set()切换全局，而是用DateTime对象显式处理：$dt = new DateTime($row['created_at'], new DateTimeZone('UTC')); $dt->setTimezone(new DateTimeZone($userTimezone)); echo $dt->format('Y-m-d H:i:s');
MySQL TIMESTAMP vs DATETIME 的时区陷阱
很多人以为只要 PHP 时区设对了，数据库时间就自动同步。错。MySQL 的 TIMESTAMP 类型会隐式转成 server 时区存储和读取，而 DATETIME 完全不感知时区——它存啥就是啥，不转换也不解释。
后果很直接：如果 PHP 写入前用 date('Y-m-d H:i:s') 拼字符串插进 DATETIME 字段，那存进去的就是本地时区时间；换一个时区用户查出来，时间就偏了。
立即学习“PHP免费学习笔记（深入）”；
- 必须用
TIMESTAMP（且确保 MySQLtime_zone全局设为'+00:00'），或更稳妥地：所有时间字段用TIMESTAMP，PHP 层一律传 UTC 时间戳或 ISO8601 字符串（如'2024-05-20T08:00:00+00:00'） - 检查 MySQL 当前时区：
SELECT @@global.time_zone, @@session.time_zone;，别信配置文件里写了就生效，重启后可能被 systemd 或容器环境覆盖 - PDO 插入时避免用
date()拼字符串，改用new DateTime('now', new DateTimeZone('UTC'))->format('Y-m-d H:i:s')
Laravel / Symfony 等框架里时区配置只是“默认值”，不是解决方案
框架文档里写的 config/app.php 中 'timezone' => 'Asia/Shanghai'，只控制 now()、Carbon::now() 默认构造时的时区，跟用户无关。你调 Auth::user()->posts()->latest()->first()，拿到的模型里 $post->created_at 是 Carbon 实例没错，但它的时间值来自数据库，不会因为你改了 config 就自动重算。
- Carbon 本身支持动态切换时区：
$post->created_at->tz($user->timezone)->toDateTimeString()，但得每个展示点手动调，容易漏 - 更实用的做法是在 Eloquent 模型中加访问器：
protected $appends = ['created_at_local']; public function getCreatedAtLocalAttribute() { return $this->attributes['created_at'] ? (new Carbon($this->attributes['created_at']))->tz(Auth::user()?->timezone ?? 'UTC') : null; } - 注意：不要在访问器里直接改
$this->created_at原值，否则会影响后续 save、diff 等逻辑
API 接口返回时间字段必须带时区信息，不能只传“本地时间字符串”
前端 JavaScript 用 new Date('2024-05-20 14:30:00') 解析时，会按浏览器本地时区解释这个字符串。如果后端返回的是没时区的 "2024-05-20 14:30:00"，东京用户看到的是东九区时间，纽约用户看到的却是美东时间——其实根本不是同一时刻。
- API 返回一律用 ISO8601 带时区格式：
"2024-05-20T14:30:00+09:00"或更推荐 UTC："2024-05-20T05:30:00Z" - PHP 生成方式：
(new DateTime($time, new DateTimeZone('UTC')))->setTimezone(new DateTimeZone($userTimezone))->format(DateTimeInterface::ISO8601) - 别依赖前端自己猜时区。哪怕你传了
timezone: "Asia/Tokyo"字段，前端仍需用该时区解析时间字符串，而不是让Date构造函数自己推断
