直接删掉不用的包最有效；需人工识别冗余依赖，注意require-dev、replace、provide、minimum-stability等字段影响；用composer depends和grep定位幽灵依赖；remove后须清理配置、use语句及重生成autoload。
直接删掉不用的包，比任何优化技巧都管用。Composer 本身不提供“自动精简依赖”的功能，所谓减少依赖数量，本质是人工识别冗余、约束版本、拆分职责的过程。
哪些 composer.json 字段实际在悄悄拉入更多依赖
很多人以为只看 require 就行，但以下字段同样会触发安装：
-
require-dev：测试工具（如phpunit/phpunit）、代码质量工具（如phpstan/phpstan）全算进依赖树，CI 环境外基本不用——上线前用composer install --no-dev是底线 -
replace和provide：它们不下载包，但会干扰依赖解析逻辑，尤其当多个包provide同一个虚拟包（如psr/log）时，可能让 Composer 选中更重的实现 -
minimum-stability和prefer-stable：设为"dev"或关闭prefer-stable会让 Composer 拉取大量不稳定分支，间接引入未收敛的依赖链
用 composer depends 和 composer show 定位“幽灵依赖”
有些包看似没被直接引用，却因传递依赖留在 vendor 里，还可能被 autoload 扫描到、影响启动性能。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查谁依赖了某个包：
composer depends monolog/monolog—— 如果返回空，说明它只是被某条深层依赖链带进来，且没人直接调用 - 查包是否真被项目代码引用：
grep -r "Monolog\Logger" app/ src/ --include="*.php" | head -3，结合 IDE 的“Find Usages”更可靠 - 确认包是否参与 autoloading：
composer dump-autoload --no-dev && grep -l "monolog" vendor/composer/autoload_*.php，如果没命中，大概率可安全移除
composer remove 后还要手动清理的三件事
执行 composer remove foo/bar 只是起点，以下动作常被跳过，导致依赖残留或运行时报错：
- 检查
config/autoload.php或框架的配置文件（如 Laravel 的config/app.php），删掉对应的providers或aliases - 搜索
use语句和字符串类名（如'FooBarClient'），特别是配置值、事件监听器、队列任务里硬编码的部分 - 运行
composer dump-autoload -o，否则旧的 classmap 还在，PHP 可能继续加载已删除包里的类，报Class not found却找不到源头
真正难的不是命令怎么敲，而是判断某个包到底“算不算业务必需”。比如一个日志驱动包，看起来只被 laravel/framework 依赖，但如果你自定义了日志通道，它就不是传递依赖，而是隐式强依赖——这类边界情况，得翻源码、跑断点、看运行时调用栈才能确认。
