用 composer install -vvv --no-cache 可精准定位内存爆炸点，-vvv 能暴露 cURL 请求、JSON 响应、RuleWatchGraph.php 等底层堆栈，末尾10行常含爆内存的铁证行。
composer install卡住时，怎么知道是哪一步在吃内存
直接看终端没输出？别猜。Composer 的内存爆炸往往静默发生——进程还在跑，但 Allowed memory size exhausted 错误可能被截断或卡在中间不打印。关键不是“它崩了”，而是“它在哪崩的”。-vvv 是唯一能暴露真实调用栈和内存分配点的开关。
-
-vvv会打出 cURL 请求头、JSON 响应体（哪怕只收到半截）、RuleWatchGraph.php这类解析器内部的堆栈，错误末尾 10 行常含in phar://.../RuleWatchGraph.php on line 52—— 这就是 SAT 求解器爆内存的铁证 - 别用
-v或-vv：它们过滤掉底层 malloc 失败信号，也跳过 autoload 生成阶段的文件读取日志 - 加
--no-cache一起跑：composer install -vvv --no-cache，避免缓存掩盖真实网络请求是否发出，确认是解析卡死还是源不可达
为什么 composer update 比 install 更容易暴露内存问题
composer update 强制重跑整个依赖求解流程，而 composer install 理论上只读 lock 文件。但一旦 lock 文件“脏”了（比如含大量 dev-master 提交哈希、嵌套 package-versions），它的解析开销反而更高——-vvv 日志里会出现反复加载同一包的 composer.json 和 autoload 映射，这就是内存爬升的源头。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer update -vvv --dry-run：不真下载，只跑求解逻辑，能快速复现内存峰值位置 - 若日志中密集出现
Reading /path/to/vendor/some/package/composer.json，说明 autoload 配置有风险（比如psr-4错映射到整个vendor/） - 若卡在
Resolving dependencies后长时间无输出，且-vvv最后一行停在RuleSetGenerator或RuleWatchGraph，基本可判定是 SAT 算法阶段内存耗尽
哪些参数组合能帮你缩小排查范围
不是所有内存问题都出在核心流程。插件、脚本、autoload 生成这些环节才是隐藏的“内存黑洞”，-vvv 能帮你定位它们是否被触发。
- 加
--no-plugins --no-scripts再跑composer install -vvv：如果不再崩，说明问题出在某个 post-install-cmd 钩子里（比如phpstan或laravel-pint的自动执行） - 加
--no-dev：如果崩得慢了或不崩了，说明require-dev里的废弃包（如symfony/class-loader）在递归解析时拖垮内存 - 加
--classmap-authoritative -o：跳过动态 autoload 查找，dump 阶段内存压力骤降；若此时-vvv日志里不再出现大量Scanning行，说明原配置里files或psr-4映射过大
CI 流水线里怎么稳定复现并捕获内存崩溃点
本地能跑通，CI 却崩？常见原因是 CI runner 的 PHP CLI 配置和你本地不同，或者 Docker 容器内存被硬限制。光靠 -vvv 不够，得让它把完整日志吐出来。
- 在 CI 脚本里显式写：
php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=1536M composer install -vvv 2>&1 | tee composer-debug.log，确保 stderr 也被记录 - 检查日志末尾是否有
PHP Fatal error: Allowed memory size of ... bytes exhausted，再往上翻 20 行，找最近一次Reading或Loading的包路径——那个包大概率是罪魁 - 如果日志里出现
fork(): Cannot allocate memory，说明不是 PHP 内存不够，而是容器系统内存不足，得调--memory=4g参数
-vvv 日志里没看到完整的堆栈和最后加载的文件路径，就等于没拿到关键线索。别跳过这一步。 
