因为 composer remove 仅更新 composer.json 和 composer.lock，不自动清理 vendor 中已安装但未被当前声明依赖的孤立包、手动复制文件或间接依赖残留，需配合 composer install、dump-autoload -o 及依赖检查工具人工验证后清理。
为什么 composer remove 后还有文件残留？
因为 composer remove 只更新 composer.json 和 vendor/ 目录下的包代码，但不会清理：已安装但未被依赖声明的孤立包（比如之前通过 composer require 临时加过又删掉的）、手动复制进 vendor/ 的代码、或被其他包间接 require 过但当前已无直接依赖的“幽灵包”。这些残留不报错，却可能干扰 autoload、引发类冲突或拖慢 dump-autoload。
用 composer show --installed + composer depends 定位真·孤立包
先跑 composer show --installed 列出所有当前 vendor 中存在的包；再对每个包执行 composer depends vendor/package-name —— 如果返回 “No package depends on vendor/package-name”，且该包没出现在 composer.json 的 require 或 require-dev 里，它就是可安全清理的孤立包。
- 注意
composer depends默认只查运行时依赖，加--tree可看依赖链，加--dev才包含 dev-only 包 -
vendor/composer/installed.php是真实安装状态来源，比composer.lock更准（lock 文件可能含已删包的旧记录） - 某些包（如插件类）可能通过 Composer 插件机制注册，需额外检查
composer.json的extra.installer-paths或plugin字段
手动清理前必须停用 autoload 缓存与插件干扰
直接删 vendor/ 子目录会破坏 autoloader 映射，导致后续 composer install 失败或 class not found。正确顺序是：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先运行
composer dump-autoload --no-scripts，避免插件在 autoload 重建时触发副作用 - 删包前，注释掉
composer.json中所有疑似关联的scripts（尤其是post-autoload-dump类钩子） - 删除目标目录后，立刻执行
composer dump-autoload -o，强制重生成映射，暴露漏删或路径错位问题
别跳过这步——很多“删了还报错”的问题，其实是 autoload cache 没刷新，不是文件真没删干净。
用 composer-unused 自动扫描 + 人工复核更可靠
composer-unused 是目前最接近“全自动识别孤立包”的工具，但它不是银弹：
- 安装：
composer global require composer-unused/composer-unused，然后在项目根目录运行composer-unused - 它会报告“未被任何 PHP 文件引用”的包，但无法判断是否被 config、env、CLI 参数等间接使用（比如一个包只提供命令行工具，但你从没在代码里
use它） - 输出中带
[unused]标记的包，需人工确认：搜项目里有没有exec('vendor/bin/xxx')、.env里是否配置了相关服务、CI 脚本是否调用了它的 bin 文件 - 它不处理部分加载的包（如只用了某个子包），建议搭配
grep -r "use.*Package\Namespace" .辅助验证
真正麻烦的从来不是删文件，而是确认“这个包到底还在不在起作用”——尤其当项目跑着老版本 Laravel 或 Symfony，有些包是框架隐式 require 的，删了会静默失败。
