PHP异步环境下date()不可靠，因时区未显式绑定、进程复用致全局污染，且date_default_timezone_set()在协程/Worker中生效范围失控；应改用DateTimeImmutable+显式时区构造。
PHP异步环境下直接调用 date() 或 strtotime() 可能返回错误时间，根本原因是时区未显式绑定、进程复用导致全局时区污染，或协程/Worker中 date_default_timezone_set() 生效范围失控。
异步场景下 date() 为何不可靠
在 Swoole、Workerman 或 PHP-FPM 的长生命周期 Worker 中，date_default_timezone_set() 是进程级的，一旦被某个请求修改，后续所有协程/请求都会继承该时区 —— 尤其当多个用户请求混用不同时区格式化时，极易串扰。另外，date() 依赖系统本地时区（TZ 环境变量），而异步运行时环境变量可能未透传或被覆盖。
- 协程内未重置时区，上一个协程设了
Asia/Shanghai，下一个协程却要输出UTC时间，结果仍是上海时间 -
strtotime('now')在不同 Worker 进程中可能因date_default_timezone_set()调用顺序不同而结果不一致 - FPM 下看似正常，但迁移到 Swoole 后突然出现时间偏移 8 小时，实际是主进程未设时区，子协程读到了空时区 fallback 到 UTC
用 DateTimeImmutable + 显式时区构造
绕过全局时区状态，每次创建独立、不可变的时间对象，确保行为可预测。这是异步环境最安全的日期处理方式。
- 永远不用
date()、strtotime()、getdate()等依赖默认时区的函数 - 用
new DateTimeImmutable('now', new DateTimeZone('Asia/Shanghai'))替代date('Y-m-d H:i:s') - 格式化统一走
->format()，不拼接字符串或手动加偏移 - 若需时间戳，用
->getTimestamp()，而非time()—— 后者不带时区上下文
use DateTimeImmutable;
use DateTimeZone;
// 安全：每次构造都绑定明确时区
$shanghaiTime = new DateTimeImmutable('now', new DateTimeZone('Asia/Shanghai'));
echo $shanghaiTime->format('Y-m-d H:i:s'); // 2024-06-15 14:30:22
$utcTime = new DateTimeImmutable('now', new DateTimeZone('UTC'));
echo $utcTime->format('c'); // 2024-06-15T06:30:22+00:00
Worker 启动时锁定默认时区并禁止运行时修改
在 Swoole/Workerman 的 WorkerStart 或 onWorkerStart 回调中设一次时区，并禁用后续修改，从源头杜绝污染。
立即学习“PHP免费学习笔记（深入）”；
- 调用
date_default_timezone_set('Etc/UTC')（推荐 UTC）或业务主时区，仅限启动阶段 - 通过
ini_set('date.timezone', 'UTC')配合date_default_timezone_set()双保险 - 在关键入口（如协程中间件）中检查
date_default_timezone_get()，若非预期值则抛异常，快速暴露误调用 - 禁止在请求处理逻辑中出现
date_default_timezone_set()—— 用DateTimeZone实例替代
注意 DateTime::createFromFormat() 的隐式时区陷阱
这个方法默认使用当前默认时区（即 date_default_timezone_get() 返回值），不是 UTC 也不是参数里写的时区 —— 很容易误以为指定了时区就安全了。
- 错误写法：
DateTime::createFromFormat('Y-m-d', '2024-01-01') → 时区来自全局，默认可能是 UTC 或空 - 正确写法：先构造带时区的
DateTimeZone，再传给DateTimeImmutable构造器，或用DateTime::setTimezone()显式切换 - 解析字符串后务必立刻绑定时区，不要依赖“解析完再 set” —— 中间状态可能被其他协程干扰
// 危险：没指定时区，用的是默认时区
$d1 = DateTime::createFromFormat('Y-m-d H:i', '2024-06-15 12:00');
// 安全：显式绑定，且用 Immutable 避免意外修改
$d2 = (new DateTimeImmutable('2024-06-15 12:00:00', new DateTimeZone('Asia/Shanghai')))
->setTimezone(new DateTimeZone('UTC'));
真正麻烦的不是“怎么转日期”，而是“谁在什么时候悄悄改了时区”。异步环境里，时间对象必须自带上下文，不能指望进程状态干净。越早放弃 date()，越少半夜查日志发现订单时间全错 8 小时。
