phpinfo显示date.timezone不对，说明修改的php.ini未被当前PHP实例加载，需先通过phpinfo()确认“Loaded Configuration File”路径，再检查并修改对应配置文件，最后重启服务。
phpinfo 显示 date.timezone 不对，说明配置没生效
这通常不是 PHP 坏了，而是你改的 php.ini 文件压根没被当前 PHP 实例加载。别急着重装或写一堆兼容逻辑——先确认你动的是“正在用的那个”配置文件。
- 新建一个
info.php，内容只有，访问它，找到 “Loaded Configuration File” 这一行，抄下路径（比如/etc/php/8.4/cli/php.ini或/usr/local/etc/php/8.4/php.ini） - 用
grep -n "date.timezone" /path/to/php.ini检查该文件里是否真有这行；如果注释了（开头是;），就删掉分号；如果压根没有，就新增一行：date.timezone = "Asia/Shanghai" - 改完必须重启服务：Apache 用
sudo systemctl restart apache2，Nginx + PHP-FPM 则要sudo systemctl restart php8.4-fpm（注意版本号匹配）
date_default_timezone_set() 调用无效？检查执行顺序和拼写
这个函数不是“设了就永远生效”，它只影响调用之后的时间操作。而且它对参数极其挑剔——写错一个字母、用了非标准名（比如 "CST" 或 "GMT+8"），PHP 就会静默回退到 UTC，还不报错。
- 必须放在脚本最开头，任何
date()、strtotime()、new DateTime()之前；框架项目建议统一写在入口文件（如index.php或public/index.php）顶部 - 只允许用 IANA 标准时区名：
"Asia/Shanghai"✅，"Asia/Chongqing"✅，"CST"❌，"GMT+8"❌ - 加个验证兜底：
if (!date_default_timezone_set('Asia/Shanghai')) { error_log('时区设置失败'); }
CLI 和 Web 环境时区不一致？别让两个 php.ini 打架
你在浏览器里看 phpinfo() 改好了，但命令行跑 php script.php 时间还是错的？大概率是 CLI 和 Web 使用了不同的 php.ini。
- 运行
php --ini查 CLI 加载的配置路径，再运行php -i | grep "Loaded Configuration File"对比 Web 环境的路径 - 两个文件都要改，或者更稳妥的做法：在脚本里统一用
date_default_timezone_set()，避开配置文件差异 - Docker 环境尤其要注意：基础镜像自带的
php.ini可能覆盖你挂载的配置，优先用docker exec -it your-php-container php --ini确认实际路径
时间还是差 8 小时？顺手检查系统时区和数据库
PHP 时区设对了，但 date() 输出仍慢/快 8 小时，问题可能出在更底层。
立即学习“PHP免费学习笔记（深入）”；
- Linux 上执行
timedatectl status，看 “Time zone” 是否也是Asia/Shanghai；如果不是，用sudo timedatectl set-timezone Asia/Shanghai同步系统时区 - MySQL 默认不自动转换时区，如果 PHP 存的是本地时间，而 MySQL 的
time_zone是+00:00，读出来就会偏移；连接后执行SET time_zone = '+8:00';或在配置里设default-time-zone='+8:00' - 别信“服务器时间准就行”——PHP 依赖的是时区标识，不是系统时间数值；哪怕系统时间是对的，时区设成
UTC，date()依然显示 UTC 时间
真正卡住人的从来不是“怎么改那一行”，而是 PHP 会安静地用一个你根本没想到的时区——比如 CLI 和 Web 配置不同、Docker 容器里覆盖了默认 php.ini、或者 date_default_timezone_set() 被某个 include 文件里的条件语句跳过了。动手前，先用三行代码验证：echo date_default_timezone_get();、echo ini_get('date.timezone');、echo date('Y-m-d H:i:s'); —— 输出才是唯一真相。
