php.ini 中 date.timezone 未生效需确认：1. 修改的是实际加载的 php.ini（用 php --ini 或 phpinfo() 查路径）；2. 值为合法 iana 名如 "asia/shanghai" 且带双引号；3. 修改后重启对应服务（apache、php-fpm 或重建 docker 容器）；4. 用 php -r "echo date_default_timezone_get(); echo ini_get('date.timezone');" 验证真实生效值。
php.ini 里 date.timezone 没生效，先确认是不是改对了文件
PHP 实际加载的 php.ini 和你编辑的很可能不是同一个——尤其 Web 和 CLI 模式常走不同配置。运行 php --ini（命令行）或在页面中调用 phpinfo()，看 “Loaded Configuration File” 那一行的路径，才是真正在用的文件。
常见错误包括：
- 改了错的
php.ini（比如改了 CLI 的，但 Web 用的是另一个） - 改了
php.ini-development或php.ini-production这类模板文件，根本没被加载 - 路径里有空格或中文，导致 Apache/Nginx 启动时静默忽略该配置
date.timezone = "Asia/Shanghai" 必须写对格式
值必须是合法 IANA 时区名，且用双引号包裹。PHP 不认 PRC、GMT+8、China 这类写法，会直接回退到 UTC 并可能报警告。
正确写法只有一种：date.timezone = "Asia/Shanghai"
错误写法示例：
-
date.timezone = Asia/Shanghai（缺双引号，部分 PHP 版本解析失败） -
date.timezone = "GMT+8"（非法时区名，date_default_timezone_set()也不接受） -
date.timezone = "Shanghai"（IANA 中没有这个独立时区）
改完 php.ini 必须重启对应服务
修改 php.ini 不是保存就生效。不同部署方式需重启的服务不同：
- Apache + mod_php：重启
apache2或httpd - Nginx + PHP-FPM：重启
php-fpm（不是只重启 Nginx） - Docker 环境：必须重建容器，或进容器内手动 reload php-fpm
不重启，phpinfo() 里看到的 date.timezone 值还是旧的；date_default_timezone_get() 返回的也仍是 UTC 或之前设的值。
验证是否真正生效，别只看 phpinfo() 页面
phpinfo() 显示的 date.timezone 值 ≠ 实际运行时生效的值。它只反映 php.ini 的原始配置，而运行时可能被 date_default_timezone_set() 或 ini_set() 覆盖。
真正要查的，是这两句输出：
php -r "echo date_default_timezone_get() . \"\n\"; echo ini_get('date.timezone');"
如果两行输出不一致，说明代码里有人提前调了 date_default_timezone_set()；如果第一行是 UTC 或空，说明设置根本没生效——这时再回头检查文件路径、格式、重启动作。
时区问题最麻烦的地方在于：它从不抛异常，date()、strtotime()、new DateTime() 全都安静地按错误时区算，直到你发现订单时间比实际晚八小时、定时任务漏跑、日志时间对不上数据库记录——那时候已经难定位了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
