replace仅在依赖解析时声明替代关系，不卸载、不安装、不覆盖文件；必须先手动composer remove原包，再配置repositories、require（含as别名）、conflict及完整autoload，否则无效。
单独写 replace 字段不会替换任何包，也不会触发安装、卸载或文件覆盖——它只在依赖解析阶段起作用，且必须配合手动清理、repositories、require 显式引用和 conflict 才可能生效。
为什么写了 replace 却没效果？
因为 replace 是包级元信息，只对定义它的那个包自身生效；项目根目录的 composer.json 里加 "replace": {"guzzlehttp/guzzle": "*"} 完全被忽略。Composer 仍按 require 列表去 Packagist 或你配的 repositories 拉取包。
- 如果
require里还写着"guzzlehttp/guzzle": "^7.0"，它就一定装原版 - 即使你 fork 了，没在
require中显式指向你的分支，Composer 就当它不存在 -
composer show guzzlehttp/guzzle还能查到结果？说明根本没被替代 -
composer depends guzzlehttp/guzzle返回 “no packages require” 才是生效信号
repositories + require + as 缺一不可
真正让 fork 包被实际安装并“冒充”原包的，是这三要素组合：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repositories：类型设为vcs，URL 指向你的 GitHub/GitLab 分支，例如{"type": "vcs", "url": "https://github.com/yourname/guzzle"} -
require：照常写原包名，但版本号得是你 fork 的分支 +as别名，例如"guzzlehttp/guzzle": "dev-main as 7.9.0" -
as后的版本必须满足其他依赖的约束（比如另一个包要求"^7.5"，你就不能 alias 成6.9） - 改完必须运行
composer update guzzlehttp/guzzle，否则缓存仍用旧版本
conflict 和 autoload 必须手动配齐
不配 conflict 的 replace 等于埋雷——安装期看似成功，运行时直接 Fatal error: Cannot declare class X。
- 在 fork 包自己的
composer.json中加："conflict": {"guzzlehttp/guzzle": "*"}，强制排除所有原包版本 - Composer 1.10+ 才完整支持
conflict与replace联动校验，老版本可能静默失败 -
autoload不继承，必须自己照原包抄全：用composer show -p guzzlehttp/guzzle查原包 autoload 类型和路径映射 - 改完立刻执行
composer dump-autoload -o，再用composer show -p your-fork-package确认规则已加载
最容易被忽略的硬性前提：必须先 composer remove
replace 不会帮你删掉已安装的包。你加完配置直接 composer install，原包依然稳稳躺在 vendor/ 里。
- 必须先手动运行
composer remove guzzlehttp/guzzle，这是不可跳过的一步 - 如果该包被其他依赖（比如
some-tool）硬 require，CI 或新机器上composer install仍会把它拉回来 - 查“钉子户”：用
composer show --tree | grep guzzlehttp/guzzle，输出非空就说明有间接依赖未升级 - 这些下游包要么升级，要么你也 fork 并 patch 其
require，否则replace在生产环境等于没写
