Artisan命令执行模型查询::all()/orderBy()->get()时无输出终止

1. 内存限制问题 #

生产环境CLI的PHP内存限制大概率比Web环境低，一次性加载5万条模型实例会吃掉大量内存。可以这么查：

• 执行php -r "echo ini_get('memory_limit');"查看CLI的内存上限，对比Web环境phpinfo里的数值
• 临时在Artisan命令开头加ini_set('memory_limit', '256M');（或者更高，比如512M）试试能不能跑通

2. PHP CLI环境配置差异 #

生产环境的PHP CLI和Web服务用的可能不是同一个php.ini，有些配置差异会导致中断：

• 执行php -ini导出CLI的全部配置，和Web环境的phpinfo输出对比，重点看max_execution_time、memory_limit、opcache这些项
• 检查CLI是否开启了zend.assertions这类调试配置，生产环境下这类配置可能触发意外终止

3. 数据库连接/查询超时 #

Web访问正常不代表CLI的数据库连接配置一致：

• 在查询前加一行DB::connection()->getPdo()->setAttribute(PDO::ATTR_TIMEOUT, 60);延长超时时间
• 去数据库服务器查慢查询日志，看看这个全表查询是不是被数据库层面的限制中断了

4. 模型全局作用域/观察者干扰 #

如果Question模型加了全局作用域或者观察者，批量查询时可能触发了没预料到的逻辑：

• 临时注释模型里的全局作用域（比如boot方法里的addGlobalScope代码）测试
• 在命令开头执行Question::unsetEventDispatcher();禁用观察者，再跑查询试试

5. 先换分批处理方案（治标也治本） #

不管问题出在哪，一次性拉5万条模型实例都不是合理做法，直接改成分批处理：

// 按1000条一批处理
Question::orderBy('id')->chunk(1000, function ($questions) {
    foreach ($questions as $question) {
        // 这里写你的数据修改逻辑
    }
});

或者用cursor()获取生成器，内存占用更低：

foreach (Question::orderBy('id')->cursor() as $question) {
    // 这里写你的数据修改逻辑
}

6. 系统层面资源限制 #

如果是容器化部署或者有服务器资源管控，可能是系统杀了进程：

• 查容器的cgroup资源限制，看是不是CPU、内存配额不够
• 看系统日志（比如/var/log/syslog或/var/log/messages），找有没有进程被OOM Killer终止的记录

内容的提问来源于stack exchange，提问作者DKage