date_default_timezone_get() 返回当前实际生效时区，如 asia/shanghai；若为 utc 或空则配置未生效，需结合 date(‘y-m-d h:i:s e’)、strtotime 对比和 datetime 行为验证时区是否真正起效。
用 date_default_timezone_get() 确认当前默认时区
这是最直接的检查方式，它返回 PHP 实际正在使用的时区，不依赖配置文件或环境变量是否“写对了”，只反映运行时生效值。
常见错误是以为改了 php.ini 就一定生效——其实 CLI 和 Web（如 Apache/FPM）可能加载不同配置，date_default_timezone_get() 能暴露这种差异。
- 在脚本开头或任意位置加
echo date_default_timezone_get();，输出应为类似Asia/Shanghai，而非UTC或空字符串 - 若返回
UTC，说明未显式设置且系统未 fallback 到预期时区；若为空，PHP 会触发警告（Warning: date(): It is not safe to rely on the system's timezone settings） - 注意：该函数不校验时区名是否合法，
date_default_timezone_set('Asia/Chn')不报错但后续时间函数会出错——得配合下一步验证
用 date('Y-m-d H:i:s e') 观察实际时间输出
光有时区名不够，得看时间计算是否按目标时区走。用带时区标识 e 的格式化输出，能同时看到本地时间和时区缩写。
例如在服务器位于美国东岸、期望显示北京时间的场景下：
立即学习 “PHP 免费学习笔记（深入）”；
- 执行
echo date('Y-m-d H:i:s e'); - 若输出
2024-06-15 14:30:22 Asia/Shanghai，说明时区已生效且时间正确 - 若输出
2024-06-15 02:30:22 America/New_York，说明date_default_timezone_set()没调用，或被后面代码覆盖 - 注意
e格式符输出的是时区名称（如Asia/Shanghai），不是缩写（CST），后者有歧义（中国标准时间 vs 中部标准时间）
对比 time() 与 strtotime('now') 在不同时区下的偏移
Unix 时间戳本身无时区，但 strtotime() 解析字符串时会受默认时区影响。这个对比能暴露“看似设了时区，实则解析逻辑仍按 UTC”的隐性问题。
典型场景：处理用户提交的“2024-06-15 10:00”这类无时区字符串。
- 先设时区：
date_default_timezone_set('Asia/Shanghai'); - 执行
var_dump(strtotime('2024-06-15 10:00'), time()); - 若两者差值接近 8 小时（即
strtotime解析结果比当前time()早或晚约 28800 秒），说明解析确实按上海时区进行；若差值接近 0，则很可能时区未生效，strtotime默认按 UTC 解析 - 此检查点特别适用于表单时间入库、定时任务触发逻辑等依赖字符串解析的业务
检查 DateTime 对象构造行为是否一致
现代 PHP 项目多用 DateTime 类，它的构造和格式化行为更严格，也更容易暴露时区配置疏漏。
- 执行
$dt = new DateTime('now'); echo $dt->format('Y-m-d H:i:s T e'); - 输出中
T（时区缩写）和e（时区全名）应匹配你设置的时区，例如CST Asia/Shanghai - 若构造时传入空字符串或
null，DateTime会使用默认时区；但若传入带时区的字符串如'2024-06-15 10:00:00 UTC'，则忽略默认时区——这点容易被忽略，导致测试误判 - 建议统一用
new DateTime('now', new DateTimeZone('Asia/Shanghai'))显式指定，避免依赖全局设置
时区是否真正起效，不取决于 ini 文件有没有写、函数有没有调，而取决于每次时间生成、解析、格式化时实际参与运算的那个时区值——它可能被框架中间件覆盖，可能被 Composer 包里的某行 date_default_timezone_set() 覆盖，也可能在 FPM pool 配置里被单独指定。最稳妥的方式，是在关键时间操作前直接打一行 date('c') 日志，而不是只信配置。
