php.ini 的 date.timezone 设置可能被运行时函数、web服务器配置或cli环境覆盖，需通过 phpinfo() 和 date_default_timezone_get() 确认实际生效值，并统一在应用启动早期显式设置时区。
php.ini 中 date.timezone 设置被覆盖
PHP 启动时会读取 php.ini，但后续通过 ini_set()、date_default_timezone_set() 或 Web 服务器配置（如 apache 的 php_admin_value）都可能覆盖它。即使你在 php.ini 里写了 date.timezone = "Asia/Shanghai"，运行时仍可能无效。
- 用
phpinfo()查看「Loaded Configuration File」路径，确认你改的是正在加载的php.ini - 搜索页面输出中「date.timezone」行，看「Master Value」和「Local Value」是否一致；不一致说明被运行时代码或服务器配置覆盖
- 检查项目入口（如
index.php）或框架初始化文件，是否调用了date_default_timezone_set("UTC")这类硬编码 - Apache 用户注意：
php_admin_value date.timezone无法被ini_set()修改，但可被date_default_timezone_set()覆盖；nginx + PHP-FPM 则常见于php-fpm.conf或 pool 配置里的php_admin_value[timezone]
date_default_timezone_set() 被多次调用且顺序错乱
这个函数不是“设置一次就全局生效”的保险锁——它只影响**当前请求生命周期内**后续的日期函数，且每次调用都会覆盖前一次。很多老项目或 CMS 插件会在不同位置反复调用它，最后生效的是最后一次。
- 全局搜索项目代码中的
date_default_timezone_set(，尤其注意 include/require 的公共文件、中间件、插件钩子 - 在关键逻辑前加一行
var_dump(date_default_timezone_get());，确认执行到那里时实际生效的时区 - 避免在循环、条件分支或模板渲染阶段调用它；应统一放在应用启动最早期（如框架
bootstrap.php头部） - 如果使用 composer 自动加载的第三方库（比如某些日志组件），它们也可能悄悄调用该函数——临时注释掉 require 行测试是否恢复
CLI 与 Web 环境时区配置不一致
你在浏览器里看到 date() 正确，但命令行运行 php artisan schedule:run 或 php script.php 却输出 UTC 时间？这是 CLI 模式读取的是另一份 php.ini（通常是 /etc/php/*/cli/php.ini），和 Web 模式（fpm 或 apache2）完全独立。
- 分别执行
php --ini（CLI）和phpinfo()（Web）对比配置路径 - 检查 CLI 对应的
php.ini是否设置了date.timezone；没设就补上，或直接在脚本开头加date_default_timezone_set("Asia/Shanghai"); - linux 下有时 CLI 使用
php7.4，而 Web 使用php8.1，版本不同导致 ini 文件路径、默认行为都不同，务必核对 PHP 版本 - docker 环境要特别注意：镜像中
php.ini可能被 ENTRYPOINT 覆盖，或通过环境变量PHP_INI_DIR指向了别处
DateTime 构造时未显式传入时区对象
即使全局时区设对了，new DateTime() 默认使用该时区，但一旦你传入时间字符串（尤其是带偏移量的），PHP 会按字符串隐含信息解析，忽略全局设置。
立即学习“PHP免费学习笔记（深入）”；
-
new DateTime("2024-01-01 12:00:00")→ 尊重date_default_timezone_set() -
new DateTime("2024-01-01 12:00:00 +0000")→ 强制解释为 UTC，无视全局时区 -
new DateTime("@1704081600")（unix timestamp）→ 总是 UTC，必须用setTimezone()手动切换 - 安全写法：
new DateTime("now", new DateTimeZone("Asia/Shanghai"))，显式绑定时区，不依赖全局状态
时区问题最麻烦的地方不在设置本身，而在于它是个“隐式上下文”——你改了一处，却可能被另一处无声覆盖；同一行代码，在 CLI 和 Web 下表现不同；甚至同一个 DateTime 实例，在构造和格式化之间被意外修改了时区。排查时优先信 date_default_timezone_get() 的实时返回值，而不是你“以为”设过的地方。