Laravel 命令行时区不一致是导致 schedule:run、tinker 等异常的隐蔽根源，需统一 CLI 与 config/app.php 时区、删除手动 date_default_timezone_set() 调用、调度中显式指定 timezone()，并检查数据库连接是否强制设时区。
命令行执行 Laravel 命令（如 php artisan schedule:run、php artisan tinker 或自定义命令）报错或行为异常，时区不一致是高频且隐蔽的根源之一。它不会直接抛出 “时区错误” 提示，而是表现为：任务不触发、时间显示偏差 8 小时、now() 返回值与预期不符、甚至出现 Invalid argument supplied for foreach() 等看似无关的报错。
确认 CLI 环境真实时区
Web 请求和命令行（CLI）是两个独立的 PHP 运行环境，它们的时区可能不同。Laravel 的 config/app.php 中设置的 'timezone' 只影响应用层逻辑，但 CLI 启动时若系统未同步，date_default_timezone_get() 仍可能返回 UTC 或其他值。
- 在终端中运行：
php -r "echo date_default_timezone_get();"—— 查看当前 CLI 默认时区 - 对比
config/app.php中的'timezone' => 'Asia/Shanghai'是否一致 - 若不一致（例如 CLI 是
UTC，而配置是Asia/Shanghai），必须统一
删掉所有手动时区覆盖代码
常见错误是在 public/index.php、artisan 文件或早期引导文件中调用了 date_default_timezone_set('UTC')。这会强行覆盖 Laravel 启动时根据 config/app.php 自动设置的时区，导致 Carbon 实例构造与格式化逻辑错乱。
- 全局搜索项目中所有
date_default_timezone_set(调用，全部删除 - Laravel 在启动时已自动执行该设置，无需、也不应手动干预
- 删完后再次运行
php -r "echo date_default_timezone_get();"，应与config/app.php完全一致
调度任务中显式指定时区（推荐）
即使全局时区已对齐，跨时区部署或共享主机场景下，仍建议在 app/Console/Kernel.php 的调度定义中显式绑定时区，避免依赖环境变量。
- 写法示例：
$schedule->command('backup:run')<br> ->dailyAt('02:00')<br> ->timezone('Asia/Shanghai'); - 该方式优先级高于全局配置，确保任务判断逻辑严格按东八区时间计算
- 配合
php artisan schedule:list可直观验证下次执行时间是否符合本地预期
检查数据库连接层是否干扰
某些命令（如数据导入、时间过滤查询）会读写数据库。若 MySQL 连接初始化时执行了 SET time_zone = '+00:00'，会导致 NOW()、CURRENT_TIMESTAMP 返回 UTC 时间，与 PHP 层时间产生错位。
- 查看
config/database.php的 MySQL 连接配置，确认'options'中无强制设时区语句 - 如需本地时区存储，应统一用 UTC 存储 + 应用层转换，而非靠数据库自动转——更可控、不易出错
- 临时验证：在 Tinker 中运行
DB::select("SELECT NOW() as now")[0]->now，看返回时间是否与now()一致
