必须修改fork包composer.json中的name字段并更新autoload配置，否则类无法自动加载；根本原因是Composer用name作为唯一标识键，重名会导致注册失败并中止。
Package name is already registered 错误怎么修
Composer 遇到包名重复时直接中止，不给任何商量余地。报错像 Package monolog/monolog is already registered 这种，说明有两个包在 composer.json 里声明了完全相同的 name 字段——不是版本冲突，是注册阶段就拒绝。
根本原因在于 Composer 内部用 name 当唯一键，URL、分支、tag 全都不算数。哪怕你 fork 了 monolog/monolog 改了几百行，只要 "name": "monolog/monolog" 没改，它就和原包“撞身份证号”。
- 别碰
repositories类型（比如从vcs改成package），改了也白改，name 一模一样照样卡住 - 删
vendor/和composer.lock后手动编辑 lock 文件强行替换路径？下次composer update会立刻还原并再次报错 - 临时加
--ignore-platform-reqs或清缓存，对 name 冲突完全无效
fork 后必须改 name 和 autoload
你 fork 的包要能被主项目识别并加载，两件事缺一不可：改 composer.json 里的 name，再同步更新 autoload 配置。
比如原包是 "name": "monolog/monolog"，你 fork 到自己仓库后，得改成类似 "name": "yourname/monolog" 这样的唯一标识。否则 Composer 解析时看到两个 monolog/monolog，根本分不清哪个是你的、哪个是 Packagist 上的。
-
autoload中的psr-4或classmap路径也要对应调整，否则类文件找不到，自动加载失败 - 改完必须重新打 tag 或推新分支，不能只改本地代码
- 主项目中
require那行要指向你新命名的包，例如"yourname/monolog": "dev-main"
私有仓库或团队镜像为什么也中招
团队私有 Packagist 或 Artifactory 镜像里，多个分支/环境用了同一 name 是常见雷区。比如 acme/utils 在 dev 分支叫 acme/utils，staging 分支也叫 acme/utils，但内部实现不同——Composer 不管内容，只认名字，直接报重名。
解决方式不是“统一源”，而是按环境或用途区分命名：
- dev 版本用
"name": "acme/utils-dev" - staging 版本用
"name": "acme/utils-staging" - 或者加命名空间前缀：
"name": "internal/acme-utils"
别指望靠 replace 或 conflict 绕过——这两个字段作用于已注册的包之间，而 name 冲突发生在注册之前，压根进不了那一步。
为什么 class not found 常和 name 冲突一起出现
表面上是类找不到，实际八成是 name 没改干净。Composer 注册失败后，可能悄悄 fallback 到旧包或跳过加载，导致 autoload 映射失效。
验证方法很简单：运行 composer show yourname/monolog。如果命令返回 “Package not found”，说明 Composer 根本没把它当有效包注册进去——99% 是 name 还没改，或者改了但没发布新版本供主项目拉取。
真正麻烦的不是改名本身，而是所有引用链都要同步更新：fork 包自己的依赖、主项目的 require、CI/CD 脚本里硬编码的包名、甚至文档里的安装命令。漏一处，就回到原点。
