composer remove 不会自动删除未被 require 的包，仅移除显式指定的包并更新配置文件，不分析反向依赖关系；安全清理需重建 vendor 目录：删除 vendor 和 composer.lock 后执行 composer install。
composer remove 会自动删掉未被 require 的包吗
不会。composer remove 只负责移除你显式指定的包，并更新 composer.json 和 composer.lock，它不扫描“哪些包当前没被任何其他包或项目代码引用”。换句话说，它不会帮你做依赖关系的反向推导。
常见错误现象：执行 composer remove old-package 后，vendor/ 里还有别的包残留，甚至有些包看似没被直接 require，但其实是某个已安装包的子依赖（transitive dependency），Composer 默认保留它们。
- 必须手动确认该包是否真的未被任何已安装包依赖——可查
composer show --tree或composer depends <package></package> - 如果只是想删掉“项目中没写在
require里的包”，但又不确定它们是否被间接依赖，别靠remove猜，用下一步更稳妥
如何安全清理所有未声明的依赖（即 vendor 中多余包）
真正清理“不再使用”的依赖，核心是重建 vendor/：只装 composer.json 中 require 和 require-dev 明确列出的包，以及它们必需的子依赖。本质是“重装可信清单”。
实操建议：
- 先备份当前
vendor/（可选，防误操作）：mv vendor vendor.bak - 删掉整个
vendor/和composer.lock：rm -rf vendor composer.lock - 运行
composer install—— 这会按composer.json重新解析依赖树，生成新composer.lock，并只装真正需要的包 - 对比
vendor.bak和新vendor，看哪些包消失了：它们就是之前未被声明、也未被任何声明包依赖的“孤儿”
注意：composer update 不行——它会升级版本、保留旧锁文件中的包，无法剔除“历史遗留孤儿”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么不能直接删 vendor 里的某个文件夹
手动删除 vendor/some-unused-package 看似快，但极大概率导致后续命令失败或行为异常。
原因包括：
-
composer dump-autoload仍会扫描旧 autoload 规则，可能报Class not found错误 -
composer show、composer depends等命令依赖composer.lock和已安装状态，状态不一致时输出不可信 - 某些包注册了 Composer 插件（如
incenteev/composer-parameter-handler），删物理文件但没卸载插件逻辑，下次 install/update 可能崩溃 - Autoloader 的 class map 或 PSR-4 映射缓存（如
vendor/composer/autoload_classmap.php）不会自动更新，造成类加载错乱
清理后还要检查什么
重建 vendor/ 后，不能默认万事大吉。最容易被忽略的是：
- 检查
autoload和autoload-dev段是否还引用了已删包里的类路径（比如旧的files或psr-4映射） - 运行
composer dump-autoload -o强制刷新自动加载，再试跑一次php -m | grep -i opcache（如有 OPcache，需重启或opcache_reset()，否则旧类映射仍生效） - CI/CD 流程中若缓存了
vendor/，记得清缓存或改缓存 key，否则下次构建可能跳过 install，沿用脏的旧 vendor
真正的“不再使用”，得从声明（composer.json）、锁文件（composer.lock）、物理安装（vendor/）、自动加载（autoload_*.php）四个层面保持同步。少一个环节，就可能埋个隐性故障。
