应使用 composer remove 卸载包，它会自动删除声明、清理 vendor、更新 lock 文件并重建 autoload；手动删文件或改配置易致 autoload 错乱、类找不到及锁文件哈希不一致。

直接用 composer remove，别手删 vendor/ 或硬改 composer.json

Composer 2.2+ 内置的 composer remove 是唯一推荐方式——它不是“删文件”，而是执行一次反向安装：自动识别包在 require 还是 require-dev 里、删条目、删 vendor/vendor-name/package-name 目录、更新 composer.lock、重建 autoload 映射。整个过程原子化，失败即回退。

常见错误现象：

• 手动删掉 vendor/monolog/monolog，再删 composer.json 里那行，最后跑 composer install —— 结果 autoload 找不到类、composer show monolog/monolog 还显示已装（因 composer.lock 没同步更新）、CI 构建也可能报哈希不一致
• composer remove monolog/monolog 执行后 ls vendor/monolog 仍存在目录 —— 多半是命令中途被中断，或之前用了 --no-update 却忘了后续 composer update

实操建议：

Discussion Composer

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

下载

• 确认包名：先运行 composer show | grep monolog 或打开 composer.json 查看全称
• 开发依赖也一样：如 phpunit/phpunit，composer remove phpunit/phpunit 会自动识别它在 require-dev 里，无需加 --dev（除非同名包同时出现在两个区）
• 想跳过实时重装？加 --no-update：只改 composer.json，后续统一 composer update

遇到 “required by another package” 别硬删，这是保护机制

这不是命令失败，是 Composer 在阻止你破坏依赖图。比如你执行 composer remove guzzlehttp/guzzle，但 symfony/http-client 明确依赖它，Composer 就会中止并告诉你谁在用。

实操建议：

• 查谁在依赖它：composer why guzzlehttp/guzzle，输出会列出所有直接引用者
• 若上游包（如 symfony/http-client）也确实不需要，就一起删：composer remove symfony/http-client guzzlehttp/guzzle
• 临时调试想绕过检查？慎用 --no-update，之后 composer update 可能漏掉冲突，不推荐日常操作
• 绝对避免先删 composer.json 条目再 composer install，容易触发版本漂移，尤其锁文件有精确哈希时

删完必须人工扫代码，composer remove 不管 use、配置和注册

composer remove 只管声明和 autoload 配置，不管你的 PHP 文件里还留着多少 use MonologLogger、new Logger()、Laravel 的 config/logging.php 配置，或者 app/Providers/LoggingServiceProvider.php 里的注册逻辑。这些残留不清理，上线就 Class not found。

实操建议：

• 全局搜索关键词：grep -r "use Monolog\" . --include="*.php"（注意反斜杠转义）
• 检查 config/ 下配置文件、服务提供者、事件监听器是否硬编码调用了该包
• 运行 composer show monolog/monolog 应返回 Package not found；ls vendor/monolog 应提示 No such file or directory
• 如果 composer dump-autoload 后还能 new 出类，大概率是 autoload 缓存没刷新，或 composer.json 的 autoload.files 里还留着旧路径

autoload 没刷新？重点检查这三处

删完跑起来报 Class not found，大概率不是删失败，而是 autoloader 没生效。Composer 的自动加载分三层，每层刷新逻辑不同：

• composer dump-autoload 只重新生成 vendor/autoload_*.php，不碰 vendor/composer/autoload_*.php
• 真正影响类加载的是 vendor/composer/autoload_classmap.php 和 autoload_psr4.php，它们只在 composer install 或 composer update 时重写
• Laravel 用户还要清 config 缓存：php artisan config:clear，否则旧的 service provider 可能还注册着已删包的逻辑

特别注意：Laravel 9+ 默认开启 classmap-authoritative，删包后不 dump-autoload 就会卡在旧映射里；Docker 或 CI 环境里 autoload 缓存可能更顽固，必要时加 --optimize 或重启 PHP 进程。