“Composer队列渲染”不存在——Composer仅管理PHP依赖，不执行渲染；所谓“队列渲染”实为任务队列系统（如yii2-queue）调度ffmpeg等渲染引擎完成，Composer只负责安装相关库。
“Composer队列渲染”不是 Composer 的功能，它根本不存在——这个名字是把多个工具链的职责强行揉在一起造成的术语污染。
为什么搜索“Composer队列渲染”会得到错误答案
你看到的所谓“队列渲染”，实际是把以下三类完全独立的事物混为一谈：
- Composer：纯 PHP 依赖管理器，只管下载、安装、锁定
vendor/里的代码包 - 任务队列系统（如
yii2-queue、symfony/messenger）：负责分发和执行异步作业，比如“合成 100 帧 PNG → MP4” - 渲染引擎（如
ffmpeg、blender、three.js）：真正做图形/视频计算的进程，必须由 PHP 显式调用或通过 CLI 触发
Composer 不启动进程、不调度任务、不读取图片、不生成帧。它连 exec() 都不会自动调用——更别说“挂机导出”了。
真正想实现“多项目挂机自动导出”，得自己搭三层
这不是 Composer 能配置出来的，而是要手动串联：
- 第一层（触发）：用 Cron 或 Supervisor 监听某个目录是否有新任务文件（如
tasks/render-20260527.json），然后投递到队列 - 第二层（调度）：用
yiisoft/yii2-queue拉取任务，实例化RenderAnimationJob类，在execute()方法里写exec("ffmpeg -i frame_%04d.png -y output.mp4") - 第三层（环境）：确保运行用户对输入帧目录、输出路径、临时空间有读写权限；
ffmpeg已安装且在$PATH中；PHPdisable_functions没禁掉exec和shell_exec
Composer 只参与其中一步：帮你 composer require yiisoft/yii2-queue 把队列库装进 vendor/。其余全是你的应用逻辑。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer install 不会自动开启任何渲染任务
这是最常踩的坑——以为装完包就“活了”。事实是：
-
post-install-cmd是一次性钩子，只在composer install结束后执行一次，不能持续监听或轮询 - 它默认以当前 shell 用户身份运行，但该用户很可能没权限访问 Web 服务器的上传目录或
/tmp渲染区 - 如果命令里含
exec()，而 PHP 运行模式是php-fpm，那它跑在 Web 请求生命周期里，超时（通常 30s）后直接中断，MP4 只剩一半 - 没有错误日志捕获机制的话，
ffmpeg报错（如 No such file or directory）会被吞掉，你以为“成功了”，其实什么都没生成
所以别指望 composer install 自动挂机；挂机靠的是你写的守护进程或外部调度器，不是 Composer。
“多项目”共用一套渲染队列时的关键隔离点
如果你真有多个 PHP 项目共享一个 Redis 队列做渲染，注意这些硬性约束：
- 每个项目必须用不同
queue名称（如render:project-avsrender:project-b），否则任务互相抢占 -
composer.lock必须各自独立管理——A 项目升级ffmpeg-php到 v2.0，B 项目还卡在 v1.3，不能共用 vendor - 输出路径不能写死相对路径（如
./output/），得用绝对路径 + 项目标识符，避免 A 项目覆盖 B 项目的 MP4 - 不要在
composer.json的scripts里写长耗时命令（如"render:all": "php render.php"），它会阻塞composer update，CI 构建直接超时
名字带 “Composer” 的工具很多，但只有这个 Composer —— 它只管依赖，不管渲染。想让它“挂机”，得先承认它不会动。
