需在 composer.json 顶层添加 repositories 字段，type 设为 "vcs"，url 填 fork 仓库地址；require 中保持原包名，版本用对应分支如 "dev-main"；操作前清缓存、删 vendor 和 lock 文件，并验证 .git/config 的 origin。
如何在 composer.json 中声明 fork 仓库
Composer 默认只从 packagist.org 或配置的私有仓库拉取包，要使用自己 fork 的公开仓库（比如 GitHub 上 fork 的 monolog/monolog），必须显式告诉 Composer：「这个包的新家在这儿」。关键是在项目根目录的 composer.json 里添加 repositories 字段，并指定类型为 vcs。
常见错误是直接改 require 里的版本号或 URL——没用，Composer 不认。必须通过 repositories 注册源，再让 require 引用同一 vendor/package 名称。
-
type必须设为"vcs"（不是"git"或"package"） -
url填你 fork 后的仓库 HTTPS 或 SSH 地址，例如"https://github.com/yourname/monolog" - 不需要修改包名；只要
require中仍写"monolog/monolog": "dev-main"，Composer 就会优先从你注册的 vcs 源解析
为什么 dev-* 分支名必须和 fork 仓库一致
Composer 的 vcs 驱动会自动探测远程仓库的分支和 tag，但前提是它能成功 clone 并读取 composer.json。如果你 fork 后把默认分支改成了 main，而原包用的是 master，那用 "dev-master" 就会报 Could not find package monolog/monolog at version dev-master——因为你的 fork 里根本没有 master 分支。
解决方法只有两个：要么在 fork 仓库中创建对应分支（如 git checkout -b master && git push origin master），要么在 require 中改用你实际存在的分支名：
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
{
"require": {
"monolog/monolog": "dev-main"
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/yourname/monolog"
}
]
}
如何确保 fork 修改被正确加载（不是缓存或旧版本）
Composer 缓存、已安装的 vendor 目录、甚至 packagist 的元数据都可能让你误以为改了没生效。最稳妥的操作流程是：
- 删掉
vendor/monolog/monolog和composer.lock - 运行
composer clear-cache（尤其当你之前试过失败的配置） - 执行
composer install或composer update monolog/monolog，观察输出里是否出现Cloning [your fork URL] - 检查
vendor/monolog/monolog/.git/config，确认 remote origin 是你的 fork 地址，不是原仓库
如果仍拉的是原包，大概率是 repositories 位置不对——它必须是 composer.json 的顶层字段，不能嵌套在 config 或 extra 里。
fork 仓库含自定义 composer.json 时要注意什么
你 fork 后若改过 composer.json（比如调整 autoload、加 replace、改 version），Composer 会按新文件解析。但有三个隐性风险：
- 如果改了
"name"字段（如改成"yourname/monolog"），那require也得同步改，否则匹配失败 - 如果删了
"version"字段或设为"dev-xxx"，Composer 会按 commit hash 当作版本号，composer update可能不自动拉最新 commit——需加--with-dependencies或手动git pull后composer update - 若原包用了
dist模式（zip 包），而你的 fork 没打 tag，Composer 可能 fallback 到source（git clone），影响安装速度
真正麻烦的不是配置本身，而是团队协作时没人记得这个 fork 存在——composer.lock 里不会体现仓库来源，只记 commit hash。下次别人 composer install，只要 packagist 上还有同名包，就可能悄悄切回原源。
