composer remove 是唯一能同步清理声明、文件、锁和自动加载的原子操作，但需 Composer ≥2.5 且目标包显式声明在 require 或 require-dev 中；否则应改用 composer require vendor/package: 或手动清理代码与配置。
composer remove 是唯一能同步清理声明、文件、锁和自动加载的原子操作，但必须确认 Composer 版本 ≥ 2.5，且目标包确实在 composer.json 的 require 或 require-dev 中显式声明。
怎么确认 composer remove 能用
运行 composer --version，低于 2.5 时该命令不可用或行为异常。2.2–2.4 版本需手动启用插件，2.5+ 才默认内置并稳定支持。若报错 Command "remove" is not defined，说明版本不达标，此时应改用 composer require vendor/package:（末尾冒号）替代——这是官方隐式支持的“卸载语法”，兼容所有 2.x 版本。
检查包是否真在你的项目顶层声明：grep -n "vendor/package" composer.json，注意同时查 require 和 require-dev 两处。如果没找到，说明它是间接依赖，composer remove 会直接报错 Package "xxx" is not required in your composer.json，这不是命令失败，而是设计如此。
执行 composer remove 后为什么 vendor 里还有文件
这是正常现象，不是命令失效。2.5+ 默认会删 vendor/vendor-name/package-name 目录，但某些异常状态（如部分安装失败、锁文件损坏）下，它只更新 composer.json 和 composer.lock，不碰磁盘。真正触发物理删除的是后续的 composer install 或 composer update。
不要手动删 vendor/ 下的目录——Composer 不感知，下次 composer install 可能跳过重装，导致 autoload 映射错乱。推荐补一步：运行 composer install（按 lock 文件重建）或更安全的 composer update --with-dependencies（只更新受影响分支）。
删完务必跑 composer dump-autoload -o，否则旧类仍可能被加载，尤其用了 PSR-4 或 classmap 时。OPcache 未清也会让 Class not found 错误延迟暴露。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
删了包还报 Class not found 怎么办
composer remove 不处理代码里的硬引用，也不清理配置和服务注册。最常踩的坑是：
- PHP 文件中仍有
use、new、class_exists()等调用，尤其是app/Console/Commands/或app/Providers/下的类 -
config/app.php（Laravel）或services.yaml（Symfony）里残留服务提供者、Facade 或扩展配置 -
composer.json的autoload或autoload-dev区块里还留着已删包的 PSR-4 映射 - 某些包带
post-remove脚本，但极少实现，别默认依赖
验证方式：全局搜索包名关键词（注意大小写和命名空间缩写），运行 composer show vendor/package 应报 Package not found，再查 ls vendor/vendor-name 应提示 No such file or directory。
遇到 “required by another package” 别硬删
这不是报错，是保护机制。比如 composer remove guzzlehttp/guzzle 被拒，通常因为 symfony/http-client 明确依赖它。先查依赖链：composer why guzzlehttp/guzzle 或 composer depends guzzlehttp/guzzle。
若确实不需要上游包，可接受 Composer 提示的降级/移除建议（按 y 确认）；若只是临时调试，可用 --no-update 跳过实时重装，但后续 composer update 可能漏掉冲突，不推荐日常使用。
真正麻烦的从来不是删包本身，而是那些没写在 composer.json 里、却活在 app/ 目录下对旧包的隐式调用——它们不会报错，只会在某个边缘路径里突然抛出 Class not found。
