PHP 8 时区处理核心是统一用 UTC 存储计算、本地化展示，必须显式设置时区（php.ini 或入口文件），禁用 date()/strtotime() 做业务逻辑，数据库推荐 TIMESTAMP 或 DATETIME+UTC 约定，对象创建必传 DateTimeZone。
PHP 8 设置时区的关键不是“选对函数”，而是建立一套不依赖环境、不混淆概念的处理习惯。默认不设时区，PHP 就按 UTC 运行；设错或漏设，时间偏移就静默发生——比如订单时间差 8 小时、统计报表跨月数据对不上。核心原则是：存储和计算用 UTC，展示才转本地时间。
必须显式设置，默认值不可信
PHP 8 不再容忍模糊时区。date.timezone 在 php.ini 中未配置，或 date_default_timezone_set() 未调用，PHP 就回退到 UTC，且不报错。这导致开发机显示正常、上线后全乱。
- 在 php.ini 中设置（推荐全局统一）：date.timezone = "Asia/Shanghai"，改完重启 PHP-FPM 或 Web 服务
- 更稳妥的做法是在项目入口文件（如 index.php 或 bootstrap.php）开头立即执行：
date_default_timezone_set("Asia/Shanghai"); - 务必检查是否生效：echo date_default_timezone_get(); 输出必须是你设的时区名，不能只信配置文件
别用 date() 和 strtotime() 做业务逻辑
这两个函数完全受默认时区控制，一旦时区错，结果就错，而且难以追踪。它们适合简单日志或调试，不适合订单创建、定时任务、跨时区比较等场景。
- 错误写法：$time = strtotime("tomorrow"); echo date("Y-m-d", $time); —— 依赖默认时区，迁移即崩
- 正确替代：$dt = new DateTimeImmutable("tomorrow", new DateTimeZone("Asia/Shanghai"))->setTimezone(new DateTimeZone("UTC")); 显式声明输入时区，立刻转为 UTC 存储
- time() 和 $_SERVER['REQUEST_TIME'] 返回的是 Unix 时间戳（UTC 瞬间），本身无时区。格式化前必须绑定时区对象，不能直接丢给 date()
数据库时间必须和 PHP 时区解耦
MySQL 的 NOW()、DATETIME 字段不带时区信息，PHP 和 MySQL 各自按自己的时区解析，一存一查就偏移。常见症状：PHP 写入 "2024-01-01 12:00:00"，查出来变成 "2024-01-01 04:00:00"。
立即学习“PHP免费学习笔记（深入）”；
- 方案一（推荐）：MySQL 表字段用 TIMESTAMP 类型，它自动转为 UTC 存储，读取时也自动转回会话时区
- 方案二：用 DATETIME + 应用层强约定 —— 所有写入前转成 UTC，所有读出后按需转本地：
$dt = new DateTime("@$dbDatetimeTimestamp", new DateTimeZone("UTC"))->setTimezone(new DateTimeZone("Asia/Shanghai")); - 连接建立后立即执行：$pdo->exec("SET time_zone = '+08:00'"); 或 "SET time_zone = 'Asia/Shanghai'"，确保 NOW() 与 PHP 一致（但不如用时间戳可靠）
用不可变对象 + 明确时区构造，杜绝隐式行为
PHP 8.1 起支持初始化器中直接 new DateTimeZone，让代码更清晰。关键是要避免 new DateTime("2024-01-01") 这类写法——它偷偷用了当前默认时区，一旦漏设，整个对象就废了。
- 创建时刻对象时，永远传入 DateTimeZone：
$dt = new DateTimeImmutable("2024-01-01 10:00:00", new DateTimeZone("Asia/Shanghai")); - 转换时区用 setTimezone()，而不是重新格式化：
$utc = $dt->setTimezone(new DateTimeZone("UTC")); - 存储或传输用 getTimestamp() 或 format('U')，拿到纯数字时间戳（UTC），彻底脱离字符串和时区干扰
