应使用 composer remove 卸载包，它原子化执行删声明、删目录、更新 lock、重建 autoload；手动删 vendor 或改 composer.json 易致 autoload 错乱、类找不到、CI 构建失败。

直接用 composer remove 不能解决已弃用包的问题——它只管“删声明”，不管“谁在用”或“代码里还藏着多少调用”。废弃提示（Package xxx is abandoned）本质是风险预警，不是错误，也不代表能一键清理。

怎么确认一个废弃包到底能不能删

先别急着执行 composer remove。废弃包分两类：你项目里直接 require 的，和被其他包拖进来的间接依赖。前者可主动替换，后者必须查清依赖链再决策。

• 运行 composer show xxx/xxx，看输出里有没有 abandoned 字样和 Recommended replacement 提示
• 执行 composer depends xxx/xxx，区分结果：
  • 如果只返回你的项目名（如 your/project），说明是直接依赖，可以进入替换流程
  • 如果返回一堆第三方包（如 laravel/framework、symfony/console），说明它是被上游硬依赖的，删不掉，得升级上游或临时处理
• 用 grep -r "use xxx\" . --include="*.php" 或 IDE 全局搜索，确认项目中是否真有调用——有些废弃包只是配置里留了个类名字符串，代码里早没用了

直接 require 的废弃包怎么安全替换

这是最可控的情况，但容易踩 API 不兼容的坑。比如从 guzzlehttp/ringphp 换到 guzzlehttp/guzzle，RingClient 类直接消失，不是改个命名空间就能跑通。

Discussion Composer

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

下载

• 先执行 composer remove xxx/xxx，它会自动删 composer.json 条目、更新 composer.lock、重建 autoload
• 立刻执行 composer require yyy/yyy:^3.0（注意版本约束，别用 ^latest；查看推荐包的 CHANGELOG，确认大版本是否破坏性升级）
• 改代码时重点盯三处：
  • 所有 use 语句和 new XxxClass() 实例化
  • 方法签名变化（比如 send() 变成 request()）
  • 配置文件里硬编码的类名（如 config/logging.php 中的 'handler' => MonologHandlerStreamHandler::class）
• 跑一遍测试，尤其关注异常路径和日志上报这类边界 case——废弃包往往在这些地方行为古怪，新包一跑就暴露旧逻辑漏洞

间接依赖的废弃包删不掉怎么办

常见现象：composer remove xxx/xxx 报错 Package is not installed，但 composer outdated 还列着它，composer depends xxx/xxx 返回一堆包名。这不是命令错了，是 Composer 在告诉你：“它不是你的，你无权删。”

• 优先查上游包的 release notes：比如 doctrine/orm v2.12+ 已切换依赖，不再拉 doctrine/common，那你升级 doctrine/orm 就自然淘汰了废弃包
• 如果上游迟迟不更新，且你又急需移除，可临时加 replace 到 composer.json：

  "replace": {
      "xxx/xxx": "*"
  }

  但这只是告诉 Composer “假装它存在”，实际代码仍调用旧类——必须同步 patch 上游包或自己 fork 修复，否则上线就是 fatal error
• 绝对不要手动删 vendor/xxx/xxx 目录：下次 composer install 会重新拉，还可能破坏 autoload 映射，导致 Class not found 却找不到来源

删完之后最容易被忽略的三件事

composer remove 只动声明和 autoload，不动你的代码、配置、服务提供者。很多线上故障就出在这三处残留上。

• 全局搜 use xxx、new Xxx、xxx::class 字符串，特别注意 config/ 和 app/Providers/ 下的硬编码
• 检查 composer dump-autoload -p 是否报错：如果失败，说明 autoload 映射里还有已删包的 PSR-4 路径，得手动清理 vendor/composer/autoload_psr4.php
• 某些包（如 phpunit/phpunit）被 require-dev 引入，但测试里用了 @requires extension mbstring 注解——移除后 PHPUnit 启动失败，得同步删测试或改断言逻辑