date_default_timezone_set() 不适合用户自定义时区场景，因其修改请求级全局时区，导致多用户污染、破坏框架逻辑、无法并存多时区；应统一使用 datetime+datetimezone 显式控制时区。
PHP 时区不能靠 date_default_timezone_set() 在请求中途反复切换来“动态生效”于所有时间函数——它只影响后续调用，且线程 / 请求级全局生效，不是 per-variable 或 per-datetime 的隔离控制。
为什么 date_default_timezone_set() 不适合用户自定义时区场景
这个函数修改的是当前请求的默认时区（PHP 内部全局状态），一旦设了，date()、strtotime()、getdate() 等所有不显式指定时区的函数都会受其影响。问题在于：
- 多个用户共享一个请求（如 CLI 批处理或长连接服务）时，互相污染
- 框架里可能已有中间件或组件提前设置了时区，你再覆盖会破坏原有逻辑
- 它无法解决“同一页面显示两个不同时区时间”的需求（比如用户本地时间 + 服务器所在时区时间）
正确做法：用 DateTime + DateTimeZone 显式构造带时区的时间对象
这是唯一可靠、可组合、可预测的方式。所有时间计算和格式化都基于对象本身携带的时区信息，完全隔离。
-
DateTime构造时传入DateTimeZone实例，或用setTimezone()切换 - 原始时间戳或字符串必须明确其“所处时区”，否则解析结果不可靠（例如
"2024-06-01 10:00"没有时区上下文就是歧义的） - 数据库存 UTC 时间戳（推荐），读出后按用户时区转换显示，避免存储本地时间带来的夏令时 / 跨年混乱
示例：
// 用户时区是 Asia/Shanghai，但想显示为 America/New_York $userTz = new DateTimeZone('Asia/Shanghai'); $utcTz = new DateTimeZone('UTC'); $nyTz = new DateTimeZone('America/New_York'); // 假设从 DB 读到的是 UTC 时间戳 $dt = new DateTime('@1717236000', $utcTz); // 2024-06-01 10:00:00 UTC $dt->setTimezone($nyTz); echo $dt->format('Y-m-d H:i:s'); // 2024-06-01 06:00:00用户时区怎么存、怎么取、怎么验证
前端拿到用户真实时区最准的方式是 JS 的 Intl.DateTimeFormat().resolvedOptions().timeZone，后端只做接收和校验，别信 $_SERVER['TZ'] 或浏览器 UA 里的模糊字段。
立即学习 “PHP 免费学习笔记（深入）”；
- 存进数据库用字符串（如
"Europe/Berlin"），别存偏移量（如"+02:00"），因为偏移量不包含夏令时规则 - 校验必须用
in_array($tz, timezone_identifiers_list(), true)，防止注入非法值导致DateTimeZone构造失败 - PHP 8.2+ 支持
DateTimeZone::listIdentifiers()，更语义化
容易被忽略的坑：strtotime() 和 date() 仍走默认时区
哪怕你全程用 DateTime，只要代码里还混着 date('Y-m-d') 或 strtotime('+1 day')，它们就无视你精心构造的 DateTime 对象，直接读 date_default_timezone_set() 的值。
- 查日志发现时间对不上？先 grep 全项目有没有漏掉的
date()调用 -
strtotime()解析无时区字符串时，会按默认时区解释——比如默认是 UTC，strtotime('2024-06-01')就是当天 00:00 UTC，不是用户本地 00:00 - CI/CD 或容器环境里，
php.ini的date.timezone可能被设成UTC，而你本地开发是Asia/Shanghai，行为不一致极易埋雷
真正要支持用户自定义时区，就得放弃所有隐式时区依赖，把时区当成时间值的一部分来传递和操作。没捷径，也别试图 patch 默认时区来“模拟”多时区——那只是把问题往后拖。
