php中date()和strtotime()默认使用date.timezone配置值，未设置时回退系统时区（如utc），易触发警告并导致跨服务器时间不一致；datetime类更可靠但需显式传入时区参数，且数据库、api等各环节均须统一时区处理。
PHP 里 date() 和 strtotime() 默认用什么时区？
它们默认使用 date.timezone 配置的值，但若没在 php.ini、.htaccess 或运行时用 date_default_timezone_set() 显式设置，PHP 会回退到系统时区（通常是 UTC 或服务器本地时区），且可能触发 E_WARNING：「It is not safe to rely on the system's timezone settings」。
这不是警告你“最好设一下”，而是明确告诉你：行为已不可控——同一段代码在不同服务器上可能产出完全不同的时间字符串。
- 检查当前默认时区：
date_default_timezone_get() - 强制设为所需时区（如东八区）：
date_default_timezone_set('Asia/Shanghai') - 注意：该函数必须在所有日期函数调用前执行，且不能在函数内多次调用覆盖
用 DateTime 类比 date() 更可靠吗？
是，但前提是别漏掉时区参数。很多人写 new DateTime('2024-01-01')，以为只是解析字符串，其实它隐式绑定当前默认时区 —— 一旦默认时区错，整个对象就错。
正确做法是显式指定输入时间和目标时区：
立即学习“PHP免费学习笔记（深入）”；
new DateTime('2024-01-01 12:00:00', new DateTimeZone('Asia/Shanghai'));
后续转换也必须用 setTimezone()，而不是靠 date() 拼接：
$dt = new DateTime('2024-01-01 12:00:00', new DateTimeZone('Asia/Shanghai'));
$dt->setTimezone(new DateTimeZone('UTC'));
echo $dt->format('Y-m-d H:i:s'); // 输出 UTC 时间
- 避免用
strtotime()解析带时区偏移的字符串（如'2024-01-01T12:00:00+08:00'），它对 ISO 8601 支持不一致 -
DateTime::createFromFormat()更可控，但需手动传入时区对象，不能依赖默认 - 数据库读出的时间戳（如 MySQL 的
DATETIME）没有时区信息，必须按业务约定补全时区上下文
MySQL 和 PHP 时区不一致导致入库/查询时间错乱
常见现象：PHP 写入 '2024-01-01 12:00:00'，查出来变成 '2024-01-01 04:00:00' —— 很可能 MySQL 服务端时区是 UTC，而 PHP 默认是 Asia/Shanghai，又没做转换。
解决方案分两层：
- 统一存储格式：MySQL 中优先用
TIMESTAMP类型（自动转为 UTC 存储），或明确用DATETIME+ 应用层全程以 UTC 处理 - 连接层同步时区：PDO 连接后立即执行
$pdo->exec("SET time_zone = '+00:00'");，或在 DSN 加;timezone=UTC（PHP 8.1+） - 读取后立刻转为业务时区：
$dt->setTimezone(new DateTimeZone('Asia/Shanghai'))，不要等到展示层才转
API 返回 JSON 时间字段怎么防时区污染？
直接 json_encode(['time' => date('c')]) 是危险的——date('c') 输出的是默认时区的 ISO 8601 字符串，前端无法判断这是本地时间还是 UTC。
规范做法只返回带明确时区标识的 UTC 时间：
$dt = new DateTime('now', new DateTimeZone('UTC'));
echo json_encode(['time' => $dt->format(DateTime::RFC3339)]); // 输出类似 "2024-01-01T12:00:00+00:00"
- 禁止返回无时区后缀的时间字符串（如
'2024-01-01 12:00:00'） - 如果业务强依赖本地时区（如日程提醒），应在字段名中体现，例如
local_time，并配套返回timezone: 'Asia/Shanghai' - 前端解析时用
new Date(str)是安全的，只要str符合 RFC 3339 或 ISO 8601 带时区格式
