直接用pcntl_fork做并发文件处理队列易出僵尸进程、资源句柄失效（如pdo断连）、孤儿进程堆积等问题，且不适用于长周期队列；推荐redis+worker模式解耦生产消费。
用 pcntl_fork 做并发文件处理队列容易出什么问题
直接上 pcntl_fork 跑多个子进程处理文件，看似简单，但实际踩坑率极高：子进程崩溃会导致孤儿进程堆积；父进程没做 pcntl_wait 回收，ps aux 里全是 Z 状态；更麻烦的是，PHP 的资源（比如 PDO 连接、cURL 句柄）在 fork 后不会自动复制或重连，子进程一用就报错 MySQL server has gone away 或 curl error 7。
所以除非你严格控制子进程生命周期、关闭所有共享资源、手动管理信号，否则不建议用 pcntl_fork 实现“批量队列”——它更适合单次派生+即用即弃的场景，不是队列。
用 Redis + php-resque 或原生 lpop/rpush 更稳妥
真正适合 PHP 批量文件处理的队列，核心是「解耦生产与消费」：一个脚本把待处理文件路径塞进 Redis 列表，另一个长期运行的 worker 脚本不断 lpop 并执行。这样失败不影响入队，重启 worker 不丢任务，还能横向加 worker。
实操建议：
- 用
rpush把文件路径推入file:queue列表，例如：redis-cli rpush file:queue "/tmp/a.pdf" "/tmp/b.jpg" - worker 脚本用
lpop阻塞取值（加 timeout 避免空转），如：$path = $redis->lPop('file:queue', 5);（注意：原生phpredis的lPop不支持 timeout，得用brpop反向操作） - 每个 worker 处理前先
set_time_limit(0)，处理后记录日志或写回file:done列表，方便追踪 - 别用
serialize()存复杂对象进 Redis，只存绝对路径字符串——简单、可读、无反序列化风险
如果必须纯 PHP 无扩展，用临时文件模拟队列要防重复和中断
没有 Redis？也不是完全没辙。可以用一个锁文件 + 任务列表文件组合实现最简队列，但必须处理两个关键点：任务执行中途中断、同一任务被多个进程同时取走。
做法示例：
- 任务列表存为 JSON 行存格式（每行一个 JSON 对象），如：
{"path":"/tmp/x.log","status":"pending"} - worker 用
fopen($file, 'c+')打开，flock($fp, LOCK_EX)加写锁，fseek到第一行非"status":"done"的位置，改写该行为"status":"processing"，再flock($fp, LOCK_UN) - 处理完再打开一次，把对应行 status 改成
"done"——不要试图“删行”，避免偏移错乱 - 每次启动 worker 先扫描一遍，把残留的
"processing"状态重置为"pending"，否则断电后任务就卡死了
为什么不用 amqp 或 beanstalkd？
它们当然更专业，但引入新服务会抬高部署成本：需要额外维护一个服务进程、配置权限、处理网络超时、增加监控维度。对“每天几百个日志压缩/图片缩略”的内部小任务来说，Redis 已经是性价比拐点——它大概率你已经在用，且 lpop/rpush 的吞吐足够覆盖大多数 PHP 文件批处理场景。
真正要注意的反而是路径安全：别让用户可控的输入进队列，否则 ../../../etc/passwd 之类可能被传进来；worker 执行前务必用 realpath() + strpos() 校验路径是否落在白名单目录下。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
