根本原因是php cli解释器的php.ini未配置时区,需通过php --ini确认实际加载路径,修改对应文件中的date.timezone为"asia/shanghai"并取消注释,cli下无需重启服务,但web环境需单独重启apache/nginx或php-fpm。

PhpStorm 运行 PHP 脚本时时间显示错误或抛出 It is not safe to rely on the system's timezone settings 警告,根本原因不是 PhpStorm 本身的问题,而是它调用的 PHP 解释器未正确配置时区 —— 你得改对那个 php.ini,而不是在 IDE 里点设置。
确认 PhpStorm 用的是哪个 php.ini
很多人直接改了 XAMPP 或系统里的 php.ini,但 PhpStorm 用的却是 CLI 模式下的另一份配置。必须先搞清它实际加载的是哪一份:
- 在 PhpStorm 中打开终端(Terminal),运行
php --ini,看输出里的Loaded Configuration File路径 - 如果用的是 Docker、WSL 或远程解释器,
php --ini结果可能和 Web 环境不同;Web 请求走的是 FPM 或 Apache 模块,CLI 走的是命令行解释器,两者 php.ini 完全独立 - 别信“一键环境面板里点开的 php.ini”——那通常是 Apache 的,而 PhpStorm 默认跑的是 CLI,除非你手动配成了 FPM
修改对应 php.ini 的 date.timezone 行
找到正确的 php.ini 后,编辑它,重点只做三件事:
- 搜索
date.timezone,删掉行首的分号(;)取消注释 - 设成标准 IANA 时区名,例如:
date.timezone = "Asia/Shanghai"(别用PRC或GMT+8,PHP 8.0+ 已不推荐) - 保存文件,**CLI 模式下无需重启任何服务**,下次运行脚本即生效;但如果你同时用这个 PHP 做 Web 开发,还得单独重启 Apache/Nginx 或 PHP-FPM 才能让浏览器请求也生效
脚本开头加 date_default_timezone_set() 是临时补救,不是替代方案
在代码里写 date_default_timezone_set('Asia/Shanghai') 确实能压住警告、让 date() 正常输出,但它掩盖了配置问题,而且有隐患:
- 如果某段逻辑在该函数调用前就用了
DateTime或strtotime(),照样报错或返回 UTC 时间 - 测试脚本、命令行工具、队列任务等容易漏掉这行,导致时间逻辑在不同入口表现不一致
- 团队协作时,别人 clone 项目一跑就错,还得翻文档找“为什么一定要在 index.php 第一行加这句”
验证是否真生效,别只看 echo date()
改完别急着写业务逻辑,先验证:
- 在 PhpStorm 新建一个
test-timezone.php,内容仅两行:<?php echo date_default_timezone_get() . "\n"; echo date('Y-m-d H:i:s'); - 运行它 —— 输出第一行必须是
Asia/Shanghai,第二行时间应与你本地系统时间基本一致(误差几秒内) - 如果第一行是
UTC或空字符串,说明 php.ini 没改对位置,或者没保存成功
最常被忽略的点:CLI 和 Web 使用两套 php.ini,改完 CLI 的,Web 请求仍可能用旧配置;反过来也一样。别假设“改了一个,另一个自动同步”。
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











