date_default_timezone_set() 必须在任何时间函数调用前执行，且仅接受IANA时区标识符（如'Asia/Shanghai'），设置后需校验date_default_timezone_get()确保生效，避免与DateTime混用导致时区不一致。
date_default_timezone_set() 必须在任何时间函数调用前执行
一旦你调用了 date()、strtotime() 或 new DateTime()，PHP 就会锁定默认时区（或触发警告），此时再调用 date_default_timezone_set() 已无效——它不会修正之前已解析的时间值。
常见错误现象：
- 脚本开头漏设，中间某处补上
date_default_timezone_set('Asia/Shanghai')，但date('Y-m-d')仍返回 UTC 时间 - 放在
if分支里（如只在$env === 'prod'时设置），测试环境不触发，结果上线后时间全错 8 小时
实操建议：
- 固定放在入口文件（如
index.php、public/index.php或框架的bootstrap.php）第一行非注释 PHP 代码位置 - 加一行校验：在设置后立刻
var_dump(date_default_timezone_get())，确认输出是预期值（比如"Asia/Shanghai"） - 不要依赖自动加载或配置类初始化时机——那些都太晚了
参数只能用 IANA 时区标识符，'GMT+8' 和 'CST' 都不行
date_default_timezone_set() 对参数极其严格：传入非法字符串（如 'GMT+8'、'CST'、'China'）会静默返回 false，不报错也不警告，极易被忽略。而后续所有 date() 调用仍走未设置状态，导致时间偏差。
立即学习“PHP免费学习笔记（深入）”；
中国大陆唯一推荐且稳定可用的是 'Asia/Shanghai'（注意不是 'Asia/Beijing'，后者不存在）；'PRC' 和 'Asia/Chongqing' 虽然历史上能用，但属于过时别名，PHP 8.2+ 可能弃用，不建议新项目使用。
实操建议：
- 用
date_default_timezone_list()查看当前环境支持的完整列表，确认目标值在其中 - 硬编码时直接复制标准值，别手敲——
'Asia/Shanghai'拼错成'Asia/shanghai'（小写）也会失败 - Docker 容器里即使
/etc/timezone设了Asia/Shanghai，PHP 仍必须显式调用该函数，不能依赖系统
date() 和 DateTime 混用时，全局时区和对象时区互不影响
这是最隐蔽的坑：date_default_timezone_set('Asia/Shanghai') 只影响 date()、strtotime() 等过程式函数；而 new DateTime('now', new DateTimeZone('UTC')) 的行为完全独立，不受其控制。
典型翻车场景：
- 代码里写了
$dt = new DateTime('now', new DateTimeZone('Asia/Shanghai'))，以为“已经设了上海时区”，但紧接着echo date('Y-m-d H:i:s')输出的还是服务器本地时间 - 微服务中一个模块用
DateTime显式传时区，另一个模块用date()依赖全局时区，结果同一时刻存进数据库的时间字段相差数小时
实操建议：
- 项目统一风格：要么全用
DateTime+ 显式DateTimeZone，要么全用date_default_timezone_set()+date()，避免混用 - 若必须共存，每次调用
date()前检查date_default_timezone_get()返回值是否符合预期 - 对关键时间逻辑（如订单创建、日志打点），强制用
new DateTime('now', new DateTimeZone('Asia/Shanghai'))并格式化输出，绕过全局时区干扰
php.ini 的 date.timezone 和运行时设置优先级关系
date_default_timezone_get() 的实际取值顺序是：先看是否被 date_default_timezone_set() 显式覆盖；没覆盖则读 ini_get('date.timezone')；都为空才 fallback 到 UTC。这意味着运行时设置永远优先于 php.ini 配置。
但问题在于：很多共享主机或容器镜像把 date.timezone 设成了 UTC，而你又忘了在脚本里调用 date_default_timezone_set()，结果整个应用就跑在 UTC 下——尤其当业务逻辑依赖“今天”“昨天”这类相对时间时，凌晨时段的数据统计会错乱。
实操建议：
- 上线前必查：在生产环境执行
echo date_default_timezone_get();，不能只信 phpinfo() 里的date.timezone配置项 - CI/CD 流程中加入检测脚本：启动时 assert(
date_default_timezone_get() === 'Asia/Shanghai')，失败即中断部署 - 如果用 Laravel、Symfony 等框架，别只改
.env，务必确认其 bootstrap 过程中确实调用了date_default_timezone_set()
真正麻烦的从来不是“怎么设”，而是“设在哪”“设成啥”“有没有被悄悄覆盖”。尤其是跨时区用户、定时任务、日志分析这些场景，一个没校验的 date() 调用就可能让几小时后的排查变成大海捞针。
