Composer依赖包重名会直接报错，因name是唯一标识键；必须修改fork包composer.json中的name字段并更新autoload配置，否则类无法自动加载。
Composer 依赖包重名时会直接报错，不自动覆盖或合并
Composer 不允许两个不同来源的包声明相同的 name（如 monolog/monolog 和你自己 fork 后改名但没改 name 的包）。一旦 composer.json 中出现重复 name，composer install 或 composer update 会中止并抛出类似错误：Package monolog/monolog is already registered。
根本原因在于 Composer 内部用 name 作为包唯一标识键，不是靠 URL 或版本号区分。所以“重名”不是语义冲突，而是注册失败。
- 常见场景：本地开发时 fork 了某个包，修改后仍保留原
"name": "vendor/package"；或团队私有仓库中多个镜像/分支用了相同包名 - 不要试图通过修改
repositories类型（如从vcs改成package）绕过校验——只要name重复，就卡住 - 临时 workaround（不推荐）：删掉
vendor/和composer.lock后手动编辑composer.lock强行替换包路径——但下次update会还原并再次报错
正确做法：必须修改 fork 包的 composer.json 中的 name 字段
这是唯一稳定、可复现、符合 Composer 设计逻辑的解法。修改后需重新发布（打 tag 或提交到分支），并在主项目中指向新地址。
- 将 fork 包的
composer.json中"name"改为带命名空间前缀的新值，例如："myorg/monolog"或"acme/monolog"（避免只加下划线如"monolog_custom"，防止未来与官方包同名） - 如果该包被其他依赖间接引用（比如 A → B → monolog/monolog），而你只想替换最底层的 monolog，则需在主项目的
composer.json中用replace或provide显式声明替代关系 - 使用
replace可“假装”已提供某包，从而跳过安装原包，例如："replace": { "monolog/monolog": "2.10.0" }但注意：这不会自动加载你的代码，你仍需确保类自动加载路径正确（见下一条）
autoload 配置必须同步更新，否则类找不到
改了包名只是让 Composer 能注册，不代表类能自动加载。如果你的 fork 包修改了命名空间或目录结构，autoload 必须对应调整，否则运行时报 Class not found。
- 检查 fork 包的
composer.json中autoload是否指向正确源码路径，例如："autoload": { "psr-4": { "Monolog\": "src/" } }若你未改动命名空间，这条可保留；若改成MyOrg\Monolog\，就必须同步更新 - 主项目执行
composer dump-autoload是必须步骤，尤其在修改了任何autoload配置之后 - 不要依赖
classmap扫描来“碰运气”——它不处理命名空间映射，仅用于无标准规范的老代码
私有包命名建议：用组织名+原包名，避免缩写和数字混淆
长期维护多个 fork 时，命名规则直接影响协作效率和 CI 稳定性。
- 推荐格式：
<your-org>/<original-vendor>-<original-name>，例如：acme/monolog-monolog或acme/php-http-guzzle6-adapter - 避免使用
fork-of-、v2-、patched-这类非语义前缀，它们无法表达归属，且在composer show列表中难以排序定位 - 如果原包名含连字符（如
php-http/guzzle6-adapter），新名中保留连字符比转驼峰更安全（Composer 对连字符无特殊处理，而大小写敏感易出错）
重名问题本身不难解决，但容易因贪快跳过 autoload 校验或命名一致性检查，导致后续调试成本翻倍。
