composer 不会自动替换 abandoned 包，仅警告；需手动修改 composer.json、删除旧包、添加新包并运行测试。
Composer 不会自动替换 abandoned 包，它只警告，不干预安装或依赖解析——你必须手动改 composer.json、删旧包、加新包、跑测试，否则警告永远只是警告。
abandoned 提示出现时，先确认它是否真被废弃且有推荐替代
别扫一眼 warning 就动手删。直接运行：composer show vendor/package-name，看输出里有没有 abandoned 和 replaced by 字段：
- 如果
abandoned : true且没replaced by，说明作者弃坑但没指路，得自己查 Packagist 页面或 GitHub README - 如果
abandoned : "new-vendor/new-package"，这就是权威替代名，优先信它，不是社区猜测 - 注意：Packagist 网页顶部的红色横幅（含
Use new-vendor/new-package instead）比命令行输出更及时，因为它是人工维护的
替换前必须查清谁在依赖它，否则删了就炸
很多 abandoned 包不是你 require 的，而是被某个第三方库拉进来的。盲目 composer remove 会触发冲突或类找不到：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
composer depends vendor/old-package查所有上层依赖者，结果可能是your/project（你能改）或some/other-lib（你不能直接动） - 如果是下游库依赖它，你有两个选择：等它升级，或 fork 它并 patch 其
composer.json中的require - 别忽略
require-dev—— 很多废弃提示来自旧版phpunit/phpunit-mock-objects这类开发期工具，它们可能早已被新版核心组件覆盖
替换不是改个包名，接口断裂才是真坑
即使包名换了，autoload 映射、命名空间、方法签名、构造参数都可能全变。比如 guzzlehttp/guzzle:^6 → ^7，GuzzleHttp\Client 构造函数从数组变成 HandlerStack 实例：
- 检查新包的
composer.json里autoload是否映射到原路径；若命名空间变了（如Monolog\Logger→Monolog\Log\Logger），就得全局搜use Monolog\并重写 - 新包若声明了
"replaces": {"old/package": "^1.0"}，说明它承诺兼容，可放心切；但多数替代包不会写这个 - 运行
composer dump-autoload -o后，务必跑单元测试，尤其关注 HTTP、缓存、序列化等高频使用场景
别用 replace 字段幻想自动替换
"replace": {"old/package": "*"} 在你自己的包里写，只对“你发布这个包给别人用”有意义；在你自己项目里写，它完全不生效：
- 想让 Composer 拉你的 fork？必须三件套齐备：
repositories（指明 Git 地址）、require（写原包名 +as别名）、composer update old/package（强制刷新） - 单独加
replace不删旧包、不改require、不配repositories，等于白写 - CI 脚本里容易忽略 warning——加
--fail-on-warning（Composer ≥2.5）能强制中断，避免带坑上线
最麻烦的不是装不上，是某天 PHP 升级后 Call to undefined method 突然报错，而那时原包已归档、Issues 关闭、没人修——替代动作拖得越久，胶水代码改得越多。
