PHP 8.4 中 date() 时间错误是因时区未正确设置：需在首次调用前执行 date_default_timezone_set('Asia/Shanghai') 或配置 php.ini 的 date.timezone 并重启服务，且必须使用 IANA 标准时区名；验证用 date_default_timezone_get()、ini_get('date.timezone') 和 date() 三行代码。
PHP 8.4 中 date() 函数返回时间与预期不符，几乎总是时区未正确设置导致的——不是函数坏了，是 PHP 不知道你想要哪个时区的时间。
为什么 date() 总显示 UTC 或其他错误时区？
PHP 启动时会按顺序查找时区配置，一旦找到就停止：先看脚本里是否调用了 date_default_timezone_set()，再查 php.ini 的 date.timezone，最后 fallback 到系统默认（通常是 UTC）。如果三者都缺失或写错，date() 就会静默用 UTC，但不报错，容易误判为“函数异常”。
-
date_default_timezone_set('Asia/Shanghai')必须在首次调用date()前执行，否则无效 -
php.ini中的date.timezone = "Asia/Shanghai"是全局方案，但修改后必须重启 Web 服务（如 Apache/Nginx + PHP-FPM）才生效 - 时区字符串必须用 IANA 标准名（如
"Asia/Shanghai"），不能写"GMT+8"或"CST"—— 这些不是合法时区标识，PHP 会静默回退到 UTC
如何验证当前生效的时区？
别猜，直接查。运行以下代码能立刻暴露真实配置来源：
echo date_default_timezone_get() . "\n";
print_r(ini_get('date.timezone'));
echo date('Y-m-d H:i:s') . "\n";
输出类似：
立即学习“PHP免费学习笔记（深入）”；
Asia/Shanghai Asia/Shanghai 2025-04-05 14:23:01
如果第一行是 UTC 或空字符串，说明 date_default_timezone_set() 没生效或没调用；如果第二行为空但第一行有值，说明是脚本里设的；如果两行一致且非空，说明 php.ini 配置已加载。
PHP 8.4 特别注意：DateTime 构造行为更严格
PHP 8.4 对 new DateTime() 的时区推导做了增强校验。如果你写 new DateTime('2025-04-05') 且没传第二个时区参数，它会优先使用 date_default_timezone_get() 结果；但如果该结果非法（比如拼写错误），8.4 会抛出 ValueError，而旧版本可能默默用 UTC。所以：
- 显式传时区最安全：
new DateTime('now', new DateTimeZone('Asia/Shanghai')) - 避免依赖隐式时区，尤其在 CLI 环境下（CLI 和 Web 的
php.ini可能不同） - 检查
php --ini输出的配置路径，确认你改的是正在被加载的那个php.ini
真正麻烦的从来不是改哪一行配置，而是 PHP 会安静地用一个你以为它不会用的时区——尤其是当多个 php.ini 文件共存、或 Docker 容器里覆盖了默认配置时，date() 的输出就成了“薛定谔的时区”。每次怀疑时区问题，先跑那三行验证代码，比翻文档快得多。
