是设计行为，不是 bug；composer 2.2+ 的 remove 默认同步清理 vendor 目录，但需满足无 --no-update、无中断、无间接依赖等前提，否则仅更新 composer.json 和 composer.lock。

composer remove 后 vendor 目录还有文件？这是设计行为，不是 bug

Composer 2.2+ 的 composer remove 默认会同步清理 vendor/ 下对应目录，但前提是没加 --no-update、执行过程没中断、且该包未被其他已安装包间接依赖。如果它卡在“只改了 composer.json 和 composer.lock”，那物理删除就压根没触发——这完全正常。

常见错误现象：composer remove monolog/monolog 成功退出，ls vendor/monolog 却仍存在；或者 composer show monolog/monolog 还能查到版本号。

• 先确认 composer.json 的 require 或 require-dev 区块里已无该包（注意大小写、vendor 名拼写）
• 运行 composer install —— 这是最稳妥的同步动作；composer update 会升级其他包，不适合纯清理场景
• 若怀疑 composer.lock 污染（比如之前手动改过），可删掉 composer.lock 再跑 composer install（仅限开发环境）

autoload 映射里还残留已删包的路径？必须强制重建

composer dump-autoload -o 不是可选步骤，而是必须补上的操作。旧的 vendor/composer/autoload_psr4.php 或 autoload_classmap.php 可能仍含已删包的命名空间映射，导致类看似“还能加载”，实则引用的是废弃代码。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 运行 composer dump-autoload --classmap-authoritative -o 强制重建所有映射（Laravel 9+ 默认启用 classmap-authoritative，不执行这步必出问题）
• 手动打开 vendor/composer/autoload_*.php，搜索目标包名，确认相关条目已消失
• 如果用了 OPcache 或 APCu，记得调用 opcache_reset() 或 apcu_clear_cache()，否则 PHP 还可能从缓存里拉出旧映射

代码和配置里还有 use/new/服务提供者？这些 composer remove 完全不管

composer remove 只管声明和自动加载映射，不碰你的源码、框架配置、环境变量或运行时注册逻辑。这些才是上线后报 Class not found 或 Driver not supported 的真实原因。

• 全局搜索包名关键词：grep -r "monolog\|Monolog" . --include="*.php" --include="*.js" --include="*.env"，重点看 config/、app/Providers/、routes/ 和 .env
• Laravel 项目务必检查 config/app.php 中的 providers 和 aliases 数组；Symfony 项目检查 config/bundles.php
• 验证 Artisan 命令是否还存在：php artisan list | grep -i "monolog"，若仍有输出，说明命令类或服务提供者残留

想清掉 vendor 里所有 lock 未声明的目录？用 composer gc，但别指望它解决“逻辑冗余”

composer gc 的作用非常窄：它只扫描 vendor/，对比当前 composer.lock，把 lock 里没声明的包文件夹删掉。它不处理缓存，也不判断“这个包虽在 lock 里，但代码里根本没 use 过”这类逻辑冗余。

• 运行 composer gc 可清理历史升级残留（如旧版本解压后留下的 .git、tests/ 等），但不会动任何 lock 里还登记着的包
• 真正想识别“装了但从没 use 过”的包，得靠第三方工具：composer require --dev composer-unused/composer-unused，再运行 ./vendor/bin/composer-unused
• 检测出的包不能直接删目录，必须走 composer remove vendor/package + composer install 流程，否则 autoload 映射和锁文件会不一致

最麻烦的从来不是删 vendor 目录，而是那些藏在 app/Http/Controllers/ 里对旧类的静态调用、写死在配置里的服务别名、或是通过字符串拼接动态加载的类名——它们不会在 composer remove 时报错，只会在某个请求路径里突然崩掉。