PHP时区设置不生效的主因是date_default_timezone_set()被后续代码、框架或扩展覆盖；应于脚本最顶部立即设置，避免条件判断，并用timezone_identifiers_list()校验时区有效性，同时区分CLI与Web环境分别处理。
PHP 时区设置不生效？先确认 date_default_timezone_set() 是否被覆盖
很多 PHP 脚本在本地开发环境跑得好好的，一上服务器就报 Warning: date(): It is not safe to rely on the system's timezone settings，或者返回的时间比预期快/慢几小时。根本原因不是没设时区，而是 date_default_timezone_set() 被后续代码、框架自动加载逻辑或扩展（如 Xdebug、APCu）悄悄重置了。
实操建议：
- 在脚本最顶部（早于任何 date_* 函数调用、早于 autoload、早于框架初始化）立即调用
date_default_timezone_set('Asia/Shanghai') - 避免在配置文件里“条件性”设置时区，比如
if (!ini_get('date.timezone')) { ... }—— 因为ini_get('date.timezone')返回空字符串不等于未设置，它可能已被 ini 配置或 SAPI 层设为默认值 - 检查 php.ini 中是否设置了
date.timezone =；如果已设，date_default_timezone_set()仍可覆盖，但某些旧版 PHP（5.3 之前）会忽略覆盖
为什么 date_default_timezone_get() 返回的不是你设的值？
date_default_timezone_get() 不一定反映你手动调用 date_default_timezone_set() 的结果，它按优先级顺序读取：函数调用设置 → date.timezone ini 配置 → 系统时区（/etc/timezone 或 TZ 环境变量）→ UTC（兜底）。所以即使你写了 date_default_timezone_set('Asia/Shanghai')，只要之后某处又调用了 date_default_timezone_set('UTC')，date_default_timezone_get() 就会返回 UTC。
排查方法：
立即学习“PHP免费学习笔记（深入）”；
- 在关键位置插入
var_dump(date_default_timezone_get());，确认执行到某段逻辑前后的值是否一致 - 搜索整个项目代码（含 vendor）是否有多处
date_default_timezone_set调用，尤其是 Laravel 的Illuminate/Support/DateFactory.php或 ThinkPHP 的初始化文件中可能隐式重设 - 注意 CLI 和 Web SAPI 的 php.ini 可能不同，
php -i | grep timezone和phpinfo()输出的date.timezone值未必一致
兼容 PHP 5.1 到 8.3：安全写法要绕过 E_WARNING 并检测有效性
直接调用 date_default_timezone_set('Foo/Bar') 在时区名错误时会触发警告且返回 false，但很多老项目没开错误报告，导致失败静默。PHP 5.1+ 支持 timezone_identifiers_list() 校验，但要注意它返回的是完整列表（约 400+ 项），别用 in_array() 全量遍历。
推荐写法：
// 安全设置时区，兼容 PHP 5.1+
$target_tz = 'Asia/Shanghai';
if (in_array($target_tz, timezone_identifiers_list(DateTimeZone::ASIA), true)) {
date_default_timezone_set($target_tz);
} else {
// 回退到环境变量或默认 UTC
$fallback = getenv('TZ') ?: 'UTC';
date_default_timezone_set($fallback);
}
注意：timezone_identifiers_list() 开销很小，但不要在循环里反复调用；生产环境建议硬编码白名单（如只允许 ['Asia/Shanghai', 'Asia/Shanghai', 'Europe/London']）来规避性能和安全风险。
CLI 脚本 vs Web 请求：时区设置不能共用一套逻辑
Web 请求通常由 Apache/Nginx + PHP-FPM 托管，而 CLI 脚本（如 cron、artisan）走的是独立的 PHP 进程，它们的 php.ini、环境变量、甚至用户 shell 的 TZ 都可能不同。一个常见坑是：Web 页面显示正确时间，但 php /path/to/cron.php 输出的时间却是 UTC。
解决方案：
- CLI 脚本开头强制设置：直接写
date_default_timezone_set('Asia/Shanghai');，不要依赖ini_get()判断 - 避免用
exec('date')或shell_exec('TZ=Asia/Shanghai date')获取时间 —— 这跟 PHP 内部时区无关，容易造成混淆 - 如果使用 Symfony Console 或 Laravel Artisan，应在 Command 的
handle()方法开头设时区，而不是在__construct()或服务容器绑定时设（时机太早，可能被框架覆盖）
真正麻烦的从来不是“怎么设时区”，而是“谁在什么时候把它改回去了”。上线前务必在目标环境（非开发机）用真实请求路径触发一次完整流程，并在关键节点打点输出 date_default_timezone_get() 和 date('c') 对照验证。
