date_default_timezone_set() 是唯一真正影响全局时区的函数，它设定所有时间函数（如 date()、strtotime()）的默认行为，其他方式仅提供初始值或读取当前值。
date_default_timezone_set() 是唯一真正影响全局时区的函数
php 中没有多个“时区函数”并列可用，date_default_timezone_set() 是唯一一个能修改所有时间函数（如 date()、strtotime()、getdate()）默认行为的函数。它不是“之一”，而是事实上的核心控制点。
其他看似相关的东西，比如 ini_set('date.timezone', ...) 或直接改 php.ini 的 date.timezone，本质都是在为 date_default_timezone_set() 提供初始值——如果没手动调用该函数，PHP 就会 fallback 到这些配置。
-
date_default_timezone_get()只是读取当前生效的时区，不设置 -
DateTimeZone类用于构造带时区的对象，不影响全局函数 -
time()返回 unix 时间戳，完全不涉及时区，永远是 UTC 秒数
为什么不能只靠 php.ini 设置？开发环境和线上常不一致
很多团队在生产环境的 php.ini 里写了 date.timezone = Asia/Shanghai，但本地开发机没配，或者 docker 容器镜像用了精简版 PHP 镜像（压根没设），结果一跑就报警告：It is not safe to rely on the system's timezone settings。
这不是“警告而已”，它意味着后续所有 date() 输出都可能按 UTC 走，导致日志、订单时间、缓存过期判断全错位。
立即学习“PHP免费学习笔记（深入）”；
- 必须在项目入口文件（如
index.php或框架的bootstrap.php）最开头调用date_default_timezone_set('Asia/Shanghai') - 建议加容错：检查返回值是否为
true，失败则 fallback 到UTC并记录错误 - 别用
PRC这类旧别名，PHP 8.0+ 已标记为废弃，Asia/Shanghai才是标准写法
DateTime 和 date_default_timezone_set() 的关系：不冲突，但要分清场景
有人以为用了 DateTime 就不用管全局时区了——这是误解。如果你写 new DateTime() 不传第二个参数，它**仍然依赖 date_default_timezone_set() 设置的默认时区**。
只有显式传入 DateTimeZone 对象，才脱离全局影响：
// 以下两者等价（假设已设默认为 Asia/Shanghai） new DateTime(); new DateTime('now', new DateTimeZone('Asia/Shanghai')); // 以下强制用 UTC，无视全局设置 new DateTime('now', new DateTimeZone('UTC'));- 对用户展示时间（如“下单时间：2026-02-08 16:56”）：优先用全局设置 +
date()，简洁可靠 - 跨时区计算或存储（如把用户提交的“北京时间下午3点”转成 UTC 存数据库）：必须用
DateTime显式指定源时区和目标时区 - 不要混用：避免先设全局时区，又在
DateTime里硬写Asia/Shanghai，逻辑冗余且易维护错
常见时区标识陷阱：Asia/Shanghai ≠ PRC ≠ Etc/GMT-8
这三个字符串看起来都指向东八区，但行为不同：
-
Asia/Shanghai：推荐。支持夏令时规则（虽然中国已多年不实行，但标准兼容）、被所有 PHP 版本稳定支持 -
PRC：历史遗留别名，PHP 7.4+ 警告弃用，8.0+ 直接报错，别再用 -
Etc/GMT-8：注意！这个命名是 POSIX 风格，“-”号表示**西边**，即实际是 UTC+8 —— 但语义反直觉，容易看错，且部分旧系统解析异常
验证是否生效最简单的方法就是调一下 date_default_timezone_get()，输出必须跟你设的一模一样，而不是空字符串或 UTC。
时区不是“设了就完事”的配置项，它是整个时间逻辑的地基。一旦漏设、错设或环境不一致，后面所有基于时间的判断——从 session 过期到 cron 执行时机——都会悄悄偏移，而且问题往往延迟暴露，debug 成本远高于初始化时多敲一行代码。