composer本身不产生内存泄漏，但依赖解析、元数据加载和插件执行会持续占内存不释放，尤其在ci、反复update或web环境未重启php进程时表现为“只增不减”的假性泄漏；需排查autoload重复注册、静态缓存堆积、opcache未重置及错误项目结构等问题。
Composer 本身不产生内存泄漏，但它的依赖解析、元数据加载和插件执行过程会持续占用内存且不释放——这在 CI 构建、反复 composer update 或 Web 环境中调用 Composer UI 工具时，表现为“内存只增不减”的假性泄漏。真正要查的，是它触发了哪些可复现的内存累积行为。
怎么确认是不是 Composer 导致的内存增长
先排除 PHP 进程复用带来的错觉：CLI 场景下 composer install 执行完就退出，不存在“残留内存”；但如果是在 PHP-FPM 或守护进程中反复 require 'vendor/autoload.php'，或用 Web 界面跑 Composer 命令，那问题大概率出在进程没重启，导致 autoload 注册、静态缓存、插件实例不断叠加。
- 检查入口文件是否重复
require 'vendor/autoload.php'：在public/index.php开头加echo "autoload loaded\n";，访问多次看是否输出多行 - 运行
var_dump(spl_autoload_functions());，观察是否注册了多个Composer\Autoload\ClassLoader::loadClass实例（对象 ID 不同即为不同实例） - Web 环境下确认
opcache.enable_cli=1是否开启且未配opcache.reset()，否则类定义会长期驻留
依赖分析前必须校准项目结构
所有优化命令（如 composer-unused、composer dump-autoload -o）都依赖正确的项目布局。结构错位会让分析结果完全失真——比如报“某包未使用”，上线却抛 Class not found。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer.json必须在根目录，vendor/不能嵌套（也不能放在src/或app/下） - PSR-4 映射必须三者对齐：文件路径、命名空间声明、
composer.json中的"psr-4"配置值，缺一不可 -
src/下不要混放不同命名空间的类（如同时有App\和Vendor\开头的类），否则 autoload 器会误判 -
vendor/必须被.gitignore排除，composer.lock必须提交——它是生产一致性的唯一依据
大项目依赖树怎么看才不晕
composer show -t（2.5+）或 composer show --tree（2.0–2.4）是唯一稳定可用的命令，但它必须基于已安装状态运行。全量输出动辄上千行，不加过滤等于无效。
- 查整个项目依赖链：
composer show -t .（点号不能省） - 只看生产环境（跳过 dev）：
composer show --no-dev -t .（--no-dev必须写在-t前面） - 聚焦某个包的下游：
composer show -t guzzlehttp/guzzle - 反向查谁用了
psr/log：composer show --who psr/log，加--no-dev可过滤测试依赖 - 终端宽度不够会导致缩进错位，建议用
composer show -t . | less -S或重定向到文件查看
内存瓶颈暴露与规避的关键动作
COMPOSER_MEMORY_LIMIT 不是用来“加内存”的，而是让 Composer 主动失败，从而暴露低效环节。设得太宽松（比如 -1），反而掩盖了依赖图混乱、锁文件臃肿或插件死循环等问题。
- 卡在
Loading composer repositories：大概率是远程源慢或 metadata 缓存损坏，清掉~/.composer/cache/repo/https---packagist.org/再试 - 卡在
Resolving dependencies through SAT：检查composer.json是否写了过于宽松的版本约束（如"monolog/monolog": "^1.0 || ^2.0 || ^3.0"）或minimum-stability设为dev - CI 中优先用
composer install --no-dev --prefer-dist --no-interaction，避免意外触发update求解器 - 必须
update时，绝不裸跑composer update，改用composer update package/name精准控制范围
复杂点在于：很多内存“暴涨”不是因为不够，而是某 dev 包引入了巨型依赖树，或者 lock 文件本身已损坏——此时再调高内存只是延长崩溃时间，而非解决问题。
