PHP时区必须在框架启动前通过php.ini或date_default_timezone_set()设为Asia/Shanghai，否则date()、Carbon及数据库时间操作会出错；Laravel和ThinkPHP均不自动继承php.ini时区，需手动干预并验证CLI与Web环境一致性。
PHP时区必须在框架启动前就生效，否则 date()、Carbon、数据库时间写入/查询都会出错——Laravel 和 ThinkPHP 都不自动继承 php.ini 的 date.timezone，得手动干预。
为什么 Laravel 的 config/app.php 设置有时无效
因为 'timezone' => 'Asia/Shanghai' 只影响框架内的时间封装（如 now()、Carbon::now()），但 PHP 原生函数（date()、strtotime()）仍走 PHP 运行时的默认时区。如果 php.ini 没设或设错，这些函数会回退到 UTC 或报 Warning: date(): It is not safe to rely on the system's timezone settings。
实操建议：
- 先确认
php -i | grep "date.timezone"输出是否为Asia/Shanghai；不是就改php.ini，重启 PHP-FPM 或 Apache - Laravel 中再补一层保险：在
bootstrap/app.php顶部加date_default_timezone_set('Asia/Shanghai');，早于任何服务提供者加载 - 避免在中间件或控制器里调用
date_default_timezone_set()—— 多请求并发时可能被覆盖
ThinkPHP 6 的时区配置陷阱
ThinkPHP 6 默认读取 config/app.php 中的 'default_timezone' => 'Asia/Shanghai'，但它只用于 think\helper\Str::datetime() 等辅助方法，不改变 PHP 底层行为。更隐蔽的问题是：命令行执行（如 php think queue:work）和 Web 请求可能使用不同 PHP 配置文件，导致时区不一致。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 统一在入口文件
public/index.php顶部加date_default_timezone_set('Asia/Shanghai');（TP6 推荐做法） - 检查 CLI 模式下的
php --ini，确保 CLI 版本的php.ini也设置了date.timezone = Asia/Shanghai - 数据库连接若用
timezone参数（如 MySQL 的?timezone=Asia%2FShanghai），需与 PHP 时区严格一致，否则created_at字段存的是本地时间却按 UTC 解析
验证时区是否真正生效的三步法
光看配置文件没用，得用运行时输出验证：
- 在路由闭包或控制器中打印：
echo date_default_timezone_get() . ' | ' . date('Y-m-d H:i:s') . ' | ' . (new \DateTime())->format('Y-m-d H:i:s'); - 对比
date()和\DateTime输出是否一致；不一致说明date_default_timezone_set()没起作用或被覆盖 - 查日志：用
Log::info(now())和Log::info(date('c'))同时记录，观察时间戳偏移是否相同
最容易被忽略的是 CLI 和 Web 环境的 PHP 配置分离，以及数据库连接字符串里未同步设置时区参数。这两个点一旦漏掉，线上就会出现「页面显示正确，队列任务时间错 8 小时」这类问题。
