保障核心业务：通过Composer Replace声明平替废弃第三方包-composer-PHP中文网

replace不能自动替换废弃包，必须满足三条件：你控制新包、接口兼容、且已手动移除旧包的require声明；否则composer仍会安装旧包并引发类重复加载错误。

保障核心业务：通过composer replace声明平替废弃第三方包

能用 replace 平替废弃包，但必须满足三个硬条件：你控制新包、新旧接口基本兼容、且已手动移除旧包的 require 声明——否则 Composer 会照装不误，甚至引发类重复加载 fatal error。

replace 字段只影响依赖解析，不触发安装或卸载

很多人以为在新包的 composer.json 里加了 "replace": {"old/package": "*"}，Composer 就会自动把旧包踢掉、换上新包。不是这样。

它只做一件事：当其他依赖写 "old/package": "^1.2" 时，Composer 检查到你当前项目（或某个已安装包）声明了 replace，就会认为“这个需求已被满足”，从而跳过安装 old/package ——前提是它本来就没被显式 require 进来。

如果你项目里还留着 "require": {"old/package": "^1.2"}，Composer 仍会装它，replace 完全无效
如果某个二级依赖（比如 some-sdk）的 composer.json 硬写了 "old/package": "^1.0"，而你没升级或 patch 它，replace 也会被绕过
运行 composer show old/package 仍能查到它？说明 replace 没生效；执行 composer depends old/package 返回 “no packages require” 才算成功

autoload 不继承，命名空间错位就 Class not found

replace 不会复制旧包的 autoload 配置。哪怕你接口一模一样，只要命名空间或文件路径对不上，运行时立刻报 Class not found。

必须人工对照旧包的 composer.json 中的 autoload 类型（psr-4 / classmap / files），在新包里完整复现：

旧包是 "psr-4": {"OldVendor\Helper\": "src/"}，你的新包类也在 src/ 下，但命名空间是 MyOrg\Utils\？不行，得统一成 OldVendor\Helper\ 或改 autoload 映射
旧包用了 "files": ["src/helpers.php"]，你漏掉这一行，全局函数就不可用
改完后务必跑 composer dump-autoload -o，再用 composer show -p 确认映射已注册

必须配 conflict，否则多版本共存导致 fatal error

光有 replace 不够。万一旧包因某条依赖链被拉进 vendor，而你的新包也装上了，两个包的同类名（尤其全局函数、trait、interface 实现）会冲突，PHP 直接报 Fatal error: Cannot declare class。

正确做法是在新包的 composer.json 中同时声明：

Discussion Composer

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

下载

"replace": {
  "old/package": "*"
},
"conflict": {
  "old/package": "*"
}

这告诉 Composer：“我替代它，且绝不允许它和我共存”。注意：conflict 的版本约束写 "*" 最稳妥，避免漏掉某个小版本。

另外，检查 autoload-dev 里是否引用了旧包的测试辅助类（比如 OldPackageTestCase）。这类常被忽略，导致 phpunit 在 CI 上直接失败。

真正麻烦的不是你自己的 require，而是藏在二级依赖里的硬依赖

最棘手的情况：你本地删干净了 old/package，replace 和 conflict 全配齐，composer install 也显示没装它——结果上线 CI 报错，发现 vendor/old/package 又出现了。

原因只有一个：some-third-party/sdk 的 composer.json 里写死了 "old/package": "^1.5"，而它自己又没更新。Composer 别无选择，只能装。

这时 replace 已失效，你只有两个现实选项：

给 some-third-party/sdk 提 PR 升级依赖，或等它发新版
用 repositories + require 强制指向你 fork 的该 SDK，并在 fork 里删掉对 old/package 的 require

别信“我本地跑得通就行”。二级依赖里的废弃包不会报 warning，它安静地混在 lock 文件里，直到 PHP 版本升级或扩展变更才突然崩掉。