--no-dev和--optimize-autoloader是保命开关：前者跳过dev依赖省30–50%内存开销，后者生成classmap避免psr-4动态扫描引发雪崩；二者缺一即可能在autoload重建阶段被oom killer直接杀死。
在 512MB 内存的微型容器（如轻量云主机、边缘节点、CI 构建环境）中，composer install 默认行为几乎必然触发 OOM Killer —— 不是 PHP 配置没调对，而是 Composer 自身依赖解析阶段未做资源降级，峰值内存常超 800MB。
为什么 --no-dev 和 --optimize-autoloader 是硬性前提？
这两项不是“可选优化”，而是防止进程被杀的保命开关：
-
--no-dev跳过所有require-dev包的下载与安装，省掉约 30–50% 的包元数据加载和类扫描开销 -
--optimize-autoloader强制生成 classmap，避免运行时 PSR-4 动态查找 —— 这一步在低内存下极易因递归扫描 vendor/ 目录引发内存雪崩 - 漏掉任一，即使加了
COMPOSER_MEMORY_LIMIT=128M，也大概率在 autoload 重建阶段直接被系统 kill
COMPOSER_MEMORY_LIMIT 和 php -d memory_limit 必须双设
仅设环境变量无效：Composer 启动后可能读取 php.ini 中的默认 memory_limit（比如 512M），绕过 COMPOSER_MEMORY_LIMIT 的限制。
必须显式组合使用：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
export COMPOSER_MEMORY_LIMIT=128Mphp -d memory_limit=128M $(which composer) install --no-dev --optimize-autoloader --no-progress- 若宿主机禁用
ini_set()（常见于共享主机），php -d是唯一可靠方式
clean install 比增量 install 更稳，但要注意 autoload 兼容性
删掉 vendor/ 再装，比保留旧 vendor/ 做增量 install 更省内存 —— 因为后者要加载旧包的 composer.json 做 diff，而 clean install 只读 composer.lock，路径更线性。
但注意这个前提：
- 必须确认
composer.json中的autoload段（尤其是psr-4映射）没有变更 - 如果混用了
psr-4+files，跳过 autoload 重生成会导致运行时报Class not found，这点极容易被忽略 - 建议搭配
--no-autoloader手动控制时机，而非依赖自动跳过
禁用插件和网络请求才是真正的“轻量”
很多所谓“加速插件”（如 hirak/prestissimo）在低内存下反而有害：
- 并发下载会开启多个 cURL 句柄，每个都带独立缓冲区，在 128M 限制下极易争抢堆空间
- 插件自身元数据缓存（如 repo 索引）可能膨胀，且无法被
COMPOSER_MEMORY_LIMIT约束 - 用
composer config --global repo.packagist.org false关闭远程源，再通过本地 mirror 或离线 zip 提供依赖，才能彻底规避网络抖动与 DNS 解析开销
微型容器里没有“省一点内存”的余地，只有砍掉非必要阶段、接受功能收敛，才能换来进程不被 OOM Killer 杀掉的确定性。
