PHP时区处理核心是明确归属、统一存UTC、按需转换；必须在脚本开头调用date_default_timezone_set()，DateTime需显式指定时区，禁用缩写而用IANA标准标识符。
PHP处理时区转换问题，核心不是“校准时间”，而是明确时区归属、统一存储格式、按需转换——否则date()、strtotime()、DateTime全都会出错，且错误难以复现。
为什么date_default_timezone_set()必须放在脚本最开头
这个函数只影响当前请求生命周期内所有未显式指定时区的日期操作。一旦在调用date()或new DateTime()之后才设置，PHP会先按系统默认时区（通常是UTC或空）解析，再警告你：
It is not safe to rely on the system's timezone settings
常见踩坑点：
立即学习“PHP免费学习笔记（深入）”；
- 框架自动加载了某些类或日志组件，内部已调用过
date()，此时再设时区已晚 - CLI脚本里混用
time()和date()，但没意识到time()返回的是UTC时间戳，而date()却按默认时区格式化 - 使用
ini_set('date.timezone', 'Asia/Shanghai')看似等效，但部分SAPI（如Apache模块）不支持运行时修改该ini项，仅date_default_timezone_set()可靠
DateTime构造时不传DateTimeZone等于埋雷
写new DateTime('2026-04-11')看起来没问题，但它实际依赖date_default_timezone_get()返回的值。如果某天部署到另一台服务器，默认时区是Europe/London，同一行代码就输出完全不同的本地时间。
安全做法是显式绑定时区：
$dt = new DateTime('2026-04-11 13:33:00', new DateTimeZone('Asia/Shanghai'));
$utc = $dt->setTimezone(new DateTimeZone('UTC'));
echo $utc->format('c'); // 2026-04-11T05:33:00+00:00
特别注意：
-
DateTimeImmutable比DateTime更安全，避免意外修改原对象 - 从用户输入（如表单提交的“2026-04-11 13:33”）创建时间时，必须知道该字符串属于哪个时区，不能假设是服务器本地时间
- 数据库读出的
datetime字段若没带时区信息（如MySQL的DATETIME类型），应视为“无时区上下文”，需由业务逻辑补全时区
数据库存UTC、展示转本地才是稳解
把时间存在Asia/Shanghai格式，等于把时区耦合进数据层。一旦用户分布全球，或要查“过去24小时下单量”，就得为每个用户动态算偏移，SQL变得脆弱且难索引。
正确路径：
- 入库前：用户提交“2026-04-11 13:33” + 时区
Asia/Shanghai→ 转成UTC时间戳或Y-m-d H:i:s格式存入 - 出库后：读出UTC时间 → 根据用户偏好时区（如
America/New_York）用setTimezone()转换 → 再格式化展示 - MySQL本身时区不影响PHP逻辑：只要PHP不依赖
NOW()或SYSDATE()这类服务端函数，就无需改MySQL的time_zone配置
验证是否真走通UTC路径的最快方式：临时把date_default_timezone_set('UTC')，看所有页面时间是否仍正确——如果崩了，说明哪段代码偷偷依赖了本地时区。
别信PRC、GMT+8、CST这些缩写
它们要么已被PHP废弃（如PRC），要么歧义极大（CST可能是China Standard Time，也可能是Central Standard Time），要么不被IANA时区数据库识别（GMT+8不是合法时区名）。
只认Asia/Shanghai、America/Chicago、Europe/Berlin这类完整IANA标识符。查可用列表用：
print_r(timezone_identifiers_list());
生产环境最容易忽略的一点：Docker容器或CI/CD构建机的php.ini可能和线上不一致，导致本地测试正常、上线后时间错8小时——务必在部署后第一件事执行date_default_timezone_get()确认。
