PHP时区问题核心在于“在哪设、何时设、设给谁用”：date()依赖全局时区，DateTime实例自带时区信息；应统一用DateTime，显式指定来源时区解析用户输入，数据库推荐用TIMESTAMP+UTC时间戳读写。
PHP 的时区问题本质不是“设不设”，而是“在哪设、什么时候设、设给谁用”——直接改 date.timezone 配置或在代码里硬写 date_default_timezone_set()，往往掩盖了真正出错的环节。
为什么 date() 和 DateTime 表现不一致？
因为 date() 完全依赖全局时区（date_default_timezone_get() 返回的值），而 DateTime 实例默认带时区信息：构造时不显式指定，就按当前全局时区解析字符串；但一旦用 new DateTime('2024-01-01', new DateTimeZone('Asia/Shanghai')) 显式传入时区，它就和全局设置脱钩了。
- 错误现象：
date('Y-m-d H:i:s')输出北京时间，但(new DateTime())->format('Y-m-d H:i:s')却是 UTC 时间——大概率是 CLI 环境没设时区，而 Web 服务器（如 Apache）的 php.ini 却设了 - 关键点：
date()没有“绑定时区”的概念，它永远用全局时区；DateTime对象内部存的是 UTC 时间戳 + 时区偏移，格式化时才换算 - 建议：统一用
DateTime，避免混用date()和strtotime()等老函数，否则时区逻辑会断裂
如何安全地解析用户输入的时间字符串？
用户提交的 "2024-03-15 14:30" 没有时区标识，不能假设它是本地时间——必须明确上下文。比如表单说明写了“请填北京时间”，那就该用 Asia/Shanghai 解析；如果是 API 接收 ISO 8601 格式（如 "2024-03-15T14:30+08:00"），DateTime 能自动识别时区。
- 错误做法：
new DateTime($_POST['time'])—— 字符串无时区，PHP 按全局时区解析，但全局时区可能被意外修改 - 正确做法：
new DateTime($_POST['time'], new DateTimeZone('Asia/Shanghai'))，强制指定来源时区 - 更健壮：先用
DateTime::createFromFormat()校验格式，再 setTimeZone() 转目标时区，避免模糊解析（例如'2024-03-15'在不同 locale 下可能被当成美式日期）
DateTime::setTimezone() 是转换还是重解释？
是转换：它把对象内部的 UTC 时间戳，按新时区重新计算本地时间显示。比如一个表示 “2024-01-01 00:00 UTC” 的对象，调用 setTimezone(new DateTimeZone('Asia/Shanghai')) 后，format('Y-m-d H:i:s') 输出的是 "2024-01-01 08:00:00"，但底层时间戳没变。
立即学习“PHP免费学习笔记（深入）”；
- 常见误用：
$dt->setTimezone($tz)->format(...)后又拿$dt->getTimestamp()去存数据库——这是对的，因为时间戳始终是 UTC - 危险操作：
$dt->setTimezone(new DateTimeZone('UTC'))->format('Y-m-d H:i:s')得到 UTC 字符串后，再用这个字符串新建另一个DateTime却不传时区——又掉回全局时区陷阱 - 性能提示：频繁调用
setTimezone()不影响性能，但反复创建DateTimeZone实例（尤其在循环里）可缓存复用
数据库读写时，时区最容易卡在哪？
MySQL 的 DATETIME 类型不存时区，TIMESTAMP 类型才按连接时区自动转换。PHP 默认用 mysqli 或 PDO 连接时，如果没显式执行 SET time_zone = '+08:00' 或 SET time_zone = 'Asia/Shanghai'，MySQL 就按其系统时区或连接变量处理。
- 典型症状：PHP 写入
"2024-01-01 12:00:00"到TIMESTAMP字段，查出来变成"2024-01-01 04:00:00"——说明 MySQL 服务端时区是 UTC，而 PHP 连接没声明时区 - 解决方案：PDO 连接 DSN 加
;timezone=Asia/Shanghai（PHP 7.4+），或连接后执行$pdo->exec("SET time_zone = '+08:00'") - 更推荐：所有时间字段用
TIMESTAMP，PHP 层统一用 UTC 时间戳读写，彻底规避字符串解析歧义
最常被忽略的一点：CLI 脚本和 Web 请求的 PHP 配置可能完全不同，phpinfo() 查到的 date.timezone 值，未必是命令行下 php -i 显示的那个。跨环境部署时，别只信 php.ini，要在代码入口处用 date_default_timezone_set('UTC') 主动锁死，再靠 DateTime 显式管理时区转换。
