查包的 replace 关系只能看其 composer.json 文件，composer 无命令行指令提取；replace 仅在库包中声明有效，且需配合 provide 才能确保运行时正常，否则易报 class not found。
怎么查一个包声明了哪些 replace 关系？
直接看它的 composer.json 文件——这是唯一权威来源。Composer 本身不提供命令行指令（如 composer show --replace）来批量提取 replace 信息，所有解析都在依赖安装/更新时内部完成。
实操建议：
- 用
composer show vendor/name查包基本信息，但它**不会显示 replace 字段内容**，只列 name、version、require 等 - 真正要确认 replace 声明，必须打开该包源码根目录下的
composer.json，搜索"replace"键 - 如果是已安装包，路径通常为
vendor/vendor/name/composer.json；若未安装，去 Packagist 页面点 “Source” 或 GitHub 仓库看 - 注意：有些包把 replace 写成
"replace": { "old/package": "self.version" }，这种写法意味着它只替换跟自己版本号完全一致的旧包，不是通配
replace 为什么没生效？常见失效场景
replace 是依赖解析阶段的“逻辑跳过”，不是运行时重定向，所以很多你以为它该起作用的地方，其实根本没触发。
典型失效现象：
- 你在项目根
composer.json里写了"replace": { "monolog/monolog": "*" }—— 这是无效的。replace 只在**库包（library）的 composer.json 中声明才有效**，项目根配置中 ignore 掉 - 其他包明确
require了被 replace 的包（比如"symfony/console": "^6.4"），而你的替代包没声明"provide": { "symfony/console": "^6.4" }—— Composer 不会自动认为你“能用”，只会报错或装原包 - 你 fork 了
laravel/framework并改名发布，但没在自己的composer.json里写"replace": { "laravel/framework": "^10.0" }—— 那么即使你加了repositories，Composer 仍会尝试装原版，因为没告诉它“我就是它” - 版本约束写得太窄，比如原包要求
"^2.8 || ^3.0"，你却只写"replace": { "psr/log": "^2.8" }—— 缺失对 ^3.0 的覆盖，解析失败
replace 和 provide 必须一起用吗？什么时候单用就够了？
不必须，但绝大多数可靠场景下，二者配合才真正安全。单独用 replace 很容易导致运行时报 Class not found 或 Declaration must be compatible。
区别很实在：
-
replace的作用：让 Composer **不装那个包**（连它的 autoload、scripts、require 都跳过） -
provide的作用：告诉 Composer **你满足某个接口契约**（比如"psr/log": "^1.0"），让它在 resolve 时把你当作合法候选 - 只写
replace：相当于“我假装是它”，但如果你没提供同名类、同签名方法，运行时立刻崩 - 只写
provide：相当于“我能干它的活”，但原包仍会被装进来，可能和你冲突（尤其 autoload 路径重叠） - 推荐组合写法：
{<br> "name": "acme/cache-adapter",<br> "provide": { "psr/cache": "^1.0", "psr/simple-cache": "^1.0" },<br> "replace": { "doctrine/cache": "^1.11" }<br>}
运行时报 Class not found，是不是 replace 搞错了？
极大概率是。replace 完全不碰自动加载规则，它只影响“装不装”，不负责“找不找得到”。只要被 replace 的包里有类被其他已安装包通过 use 或 class_exists() 引用，而你的包没提供一模一样的命名空间+路径+类名，就会在运行时炸。
排查要点：
- 检查被 replace 包的
autoload配置（尤其是classmap或深度嵌套的psr-4），你的包必须完全复刻——不只是接口，还包括类文件物理位置 - 用
composer dump-autoload -o后，打开vendor/composer/autoload_classmap.php，搜原包类名，确认是否映射到了你的文件路径 - 如果原包用了
files加载全局函数，你的包也得用相同方式注册，否则function_exists()会返回 false - 别信“我实现了接口就行”——框架核心包（如
laravel/framework、symfony/http-kernel）大量依赖具体类存在、静态方法调用、宏注册等编译期行为，replace 根本兜不住
最常被忽略的一点：replace 解决的是依赖图层面的“要不要装”，而不是代码执行层面的“能不能跑”。它看起来像捷径，实际是高风险操作，稍有偏差就得调试到深夜。
