composer运行时不会主动释放内存，退出后php进程销毁内存自然归还；真正需解决的是避免oom killer杀掉进程及削减内存峰值，关键措施为--no-dev、--no-plugins、--optimize-autoloader三者缺一不可。
Composer 运行时不会“主动释放内存”，它退出后 PHP 进程销毁，内存自然归还系统；你真正要解决的，是安装/更新过程中不被 OOM killer 杀掉，以及避免把本可省掉的内存峰值硬扛下来。
为什么 composer install 会静默退出而不是报错
不是网络问题，也不是镜像源没响应——而是 PHP 进程在 Resolving dependencies 阶段把所有包的版本约束、autoload 映射、锁文件元数据全加载进内存，轻则 800MB，重则破 1.2GB。512MB VPS 上看到命令无报错直接退出，dmesg | tail 里有 Out of memory: Kill process，就是系统级 OOM killer 动手了。
Allowed memory size exhausted 是 PHP 主动报错，说明进程还活着；静默退出 = 进程已被系统干掉。
-
COMPOSER_MEMORY_LIMIT=-1对install基本无效——它只管 Composer 自身逻辑，不管解压、symlink 这些底层 PHP 操作 - 你改的
php.ini很可能不是 CLI 用的那个：运行php --ini看Loaded Configuration File路径 -
php -d memory_limit必须显式传参，不能靠环境变量兜底
必须加的三个参数：不是优化，是保命
光提内存只是拖延时间。--no-dev、--no-plugins、--optimize-autoloader（或简写 -o）从流程上砍掉大块内存开销，漏一个，峰值可能多出 30%～60%：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-dev：跳过require-dev包（如phpunit、phpcs），Laravel/Symfony 类项目能少加载 40%+ 依赖 -
--no-plugins：禁用所有第三方插件（比如旧版hirak/prestissimo），它们会在每个包安装后触发钩子，放大串行延迟和内存竞争 -
--optimize-autoloader：生成扁平classmap，避免运行时扫描 PSR-4 目录；同时大幅降低dump-autoload阶段内存峰值
上线部署必须加：--no-dev --optimize-autoloader --classmap-authoritative
Web 环境下 autoload 重复注册才是内存暴涨主因
PHP-FPM 或 Swoole 长生命周期下，反复 require 'vendor/autoload.php' 会导致多个 Composer\Autoload\ClassLoader 实例堆积，每个实例都持有一份映射表。
- 检查是否在路由入口、中间件、CLI 命令里重复
require——只应在项目唯一入口（如public/index.php）加载一次 - 运行
var_dump(spl_autoload_functions())，如果看到多个Composer\Autoload\ClassLoader::loadClass（对象 ID 不同），就是重复注册 - Web 环境务必配
opcache.enable_cli=0（CLI 场景）或opcache.preload（FPM 场景），否则类定义不会被复用，每次require都新建 autoload 器
别信 composer --profile 能看内存，它根本不输出内存数据
composer --profile 只显示时间维度的耗时，--profile 不输出内存数据。想看真实内存足迹，必须：
- 用系统级观测：Linux/macOS 下跑
php -d memory_limit=2G composer install 2>&1 | grep "Peak memory"（Composer 2.9.6+ 自带该日志） - CI 中用
ps aux --sort=-%mem | head -5抓峰值进程，确认是不是php进程本身卡住 - 更现实的做法是加
-d memory_get_usage=true或用自定义脚本 patch，但多数场景下系统级观测已足够定位瓶颈
真正要盯的是“哪些环节在吃内存”和“怎么让 PHP 主动释放”——而 Composer 本身不泄漏内存，大型依赖图谱让它在解析、加载、注册阶段持续吃掉几百 MB，这是设计使然，不是 bug。
