PHP时区问题需以date_default_timezone_get()返回值为准，而非php.ini配置；正确设置为date.timezone="Asia/Shanghai"并重启服务，避免代码中错误调用date_default_timezone_set()或DateTime未显式指定时区。
PHP时区不对，八成是 date.timezone 没生效，或 date_default_timezone_set() 调用位置/时机错了——直接改配置并重启服务，能解决 90% 的问题；剩下的是代码里覆盖、CLI/Web 配置不一致、或框架冲突。
怎么确认当前真正生效的时区
别只看 php.ini 文件里写了啥，PHP 运行时实际用的是哪个值，得靠代码验证：
- 执行
php -r "echo date_default_timezone_get();"—— 返回值才是脚本里所有时间函数（date()、strtotime()、new DateTime()）真正依赖的时区 - 同时跑
php -r "echo ini_get('date.timezone');"—— 这个只读php.ini原始配置，和上一条结果不一致，说明被代码用date_default_timezone_set()覆盖了 - 如果第一条返回
UTC或空字符串，就坐实了问题：PHP 正 fallback 到默认行为，时间全偏了
php.ini 中 date.timezone 必须这样写
找到你实际在用的 php.ini（用 php --ini 或 phpinfo() 确认路径），修改这一行：
- ✅ 正确：
date.timezone = "Asia/Shanghai"—— 必须带双引号，且是 IANA 标准名 - ❌ 错误：
date.timezone = Asia/Shanghai—— PHP 5.4+ 开始不认无引号写法，会静默失败 - ❌ 错误：
date.timezone = "GMT+8"或"CST"—— 这些不是合法时区名，date_default_timezone_set()同样不接受 - ❌ 错误：
date.timezone = "PRC"—— 已废弃，PHP 8.1+ 会发警告
改完必须重启 Web 服务器（Apache/Nginx）或 PHP-FPM；CLI 模式下改的是另一份 php.ini，别漏掉。
立即学习“PHP免费学习笔记（深入）”；
date_default_timezone_set() 调用失败的典型场景
这个函数不是“设一次就永久有效”的全局开关，它只影响当前脚本进程，而且极易因调用时机出错：
- 在
require/include其他文件之后才调用 → 前面文件里可能已有date()执行，触发警告后 PHP 自动 fallback 到UTC，再设也晚了 - 传了非法字符串，比如
date_default_timezone_set("China/Beijing")—— IANA 数据库里根本不存在这个名称 - CLI 和 Web 模式用了不同
php.ini，你在网页里测好了，但php artisan schedule:run仍差 8 小时，大概率是 CLI 的配置没动 - 框架（Laravel、ThinkPHP）已在引导阶段设过一次，你再手动调用不会报错，但可能和框架自己的时区逻辑（如
config/app.php的timezone）冲突，导致Carbon和原生函数行为不一致
DateTime 构造时不传时区，等于埋雷
new DateTime('2024-01-01') 看似简单，但它不是“原始字符串”，而是立刻按当前默认时区解释成本地时间，再转为 UTC 存储。一旦默认时区错了，这个对象从出生起就偏了：
- 安全写法是显式传时区：
new DateTime('2024-01-01', new DateTimeZone('Asia/Shanghai')) - 从数据库读出的时间戳（int）或 UTC 字符串（如
"2024-01-01T00:00:00Z"），构造DateTime时一定要带new DateTimeZone('UTC')，否则解析出来内部时区就是错的 -
DateTime::createFromFormat()同理，第三个参数必须是DateTimeZone实例，不能是字符串
真正麻烦的不是设不对，而是设得“看起来对”：开发机配了 Asia/Shanghai，测试通过；上线后服务器系统时区是 UTC，而 php.ini 又没同步改，问题只在生产环境爆发。
