Composer 的 alias 机制仅解决同名包版本共存，无法处理同包名冲突；它只在 type: "package" 的 repositories 中生效，且需完整配置 name、version（含 as）、source，而包名重复或 autoload 冲突必须通过改名或命名空间隔离解决。
Composer 的 alias 机制不能解决同包名冲突，只能解决同名包的版本共存问题——这是两个完全不同的底层机制，混用必踩坑。
alias 只在 package 类型 repositories 中生效
你在 require 字段直接写 "monolog/monolog": "dev-main as 2.0.0"，Composer 会报 Invalid version string。alias 不是 root 包的语法糖，它只被 repositories 中 type: "package" 的定义识别。
必须显式构造一个包描述，并把 as 写进它的 version 字段：
{
"repositories": [
{
"type": "package",
"package": {
"name": "monolog/monolog",
"version": "dev-main as 2.0.0",
"source": {
"url": "https://github.com/Seldaek/monolog",
"type": "git",
"reference": "main"
}
}
}
],
"require": {
"monolog/monolog": "^2.0"
}
}
-
name必须和require中完全一致（大小写敏感） -
version字段不可省略，且必须含as；只写"dev-main"别名无效 -
source.reference要指向真实可拉取的分支或 commit，否则composer update失败 -
as右侧必须是合法语义化版本，如2.0.0或1.5.x-dev，不能是latest、master或2.0（缺补零）
同名包冲突（Package is already registered）根本不能靠 alias
当你看到 Package monolog/monolog is already registered，说明项目中（或依赖树里）有两个包声明了完全相同的 name 字段。Composer 用 name 当唯一键，不看 URL、分支或版本号。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
这种冲突发生在注册阶段，alias 还没机会介入。唯一解法是让 fork 包改名：
- 修改 fork 包的
composer.json中的name字段，比如从"monolog/monolog"改为"acme/monolog" - 同步更新你项目
repositories中的引用地址和require行 - 运行
composer show确认当前加载的包名无重复 - 用
grep -r '"name":' vendor/扫描所有依赖，揪出偷偷复用名字的包
alias 无法绕过 autoload 和类名冲突
alias 只影响依赖解析器对版本的认知，不改变实际安装的代码路径，也不干预自动加载行为。
如果两个包都声明了 "psr-4": {"Monolog\": "src/"}，哪怕用了不同别名，vendor/autoload.php 仍会把它们的类路径都注册进去。一旦出现同名类（如都定义了 MonologLogger），PHP 运行时直接报 Cannot declare class。
- autoload 不支持类名别名，
use语句级的别名只在单文件内有效 - 真要隔离类，得用命名空间迁移（改源码）或代理类封装（推荐）
- 软链 + PSR-4 显式映射可行，但部署环境需支持软链，且上游更新无法自动同步
- 别指望 alias 让不兼容的 API “看起来”兼容——它不校验行为，只骗过版本解析
alias 是个精细工具，不是万能胶。它只在「依赖树带入、未显式 require、目标包本身跨版本兼容」这三者同时成立时才安全可用。多数人卡住，是因为先遇到包名冲突，却误以为 alias 能救场——其实连门都没摸对。
