laravel队列任务内存超限会直接崩溃，需通过--memory参数限制worker进程内存上限、任务内手动监控memory_get_usage()、supervisor配置autorestart等三重防护。
队列任务内存超限直接崩溃，Laravel 默认不设上限
Laravel 本身不会主动限制单个 php artisan queue:work 进程或单个任务的内存使用——它完全依赖 PHP 的 memory_limit 配置。一旦任务（比如处理大 Excel、解析 GB 级日志）触发 PHP 内存耗尽，就会抛出 Fatal error: Allowed memory size of XXX bytes exhausted，整个 worker 进程退出，后续任务卡住，且无重试保障。
用 --memory 参数控制 worker 进程总内存上限
php artisan queue:work 提供了内置参数，能在进程级强制终止超限 worker，避免雪崩：
-
--memory=128：表示该 worker 进程**累计内存使用超过 128MB 时自动退出**（单位是 MB，不是字节） - 退出后，Supervisor 或 systemd 会拉起新进程，保证队列持续消费
- 这个值必须小于 PHP 的
memory_limit（例如 PHP 设了 256M，这里最多设 240M，留余量） - 不建议设得太低（如 64），否则简单任务也可能被误杀；也不建议等于
memory_limit，因 PHP 自身开销会导致提前触发
示例启动命令：
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
php artisan queue:work --memory=192 --timeout=60 --sleep=3
单任务内手动监控内存并主动中止
如果某个任务逻辑复杂、内存增长不可控（如递归处理嵌套 JSON、流式解压+解析），仅靠进程级限制不够，需在任务内部干预：
- 用
memory_get_usage(true)获取当前内存峰值（含未释放的分配块） - 在循环关键节点或每处理 N 条数据后检查，比如：
if (memory_get_usage(true) > 100 * 1024 * 1024) { // 超 100MB<br> Log::warning('Task memory usage too high, aborting');<br> return;<br>} - 注意：
memory_get_usage()返回的是字节，true参数表示获取分配器总申请量（更准），不加则只返回脚本层用量 - 别用
gc_collect_cycles()强制回收来“续命”——它不能解决根本泄漏，还可能拖慢执行
Supervisor 配置里补一道防线
光靠 Laravel 参数不够，因为 worker 崩溃后若 Supervisor 不重启，队列就停摆。确保你的 supervisord.conf 包含：
-
autorestart=true：崩溃后自动拉起 -
startsecs=3：新进程稳定运行 3 秒才算成功 -
stopwaitsecs=30：给queue:work优雅退出留够时间（避免 SIGKILL 硬杀） - 加上
environment=PHP_MEMORY_LIMIT="256M"，显式隔离队列进程的 PHP 配置，不影响 Web 请求
真正难控的是那些不释放资源的对象引用（如静态缓存、全局连接、未关闭的文件句柄），这类问题不会立刻爆内存，但会随任务重复执行缓慢累积——得靠 xdebug.profiler_enable_trigger 或 blackfire 抓真实堆栈，不能只盯着 --memory。
