内联别名在 require 字段中必须写为 "vendor/package": "dev-main as 2.0.0" 格式，as 右侧须为精确版本号（如 2.0.0），不可用范围约束；仅配合 vcs 类型 repositories 生效，且依赖求解时将该分支映射为指定版本参与约束匹配。
内联别名（alias）在 require 字段里怎么写才生效
内联别名只在 require 中声明时起作用，且必须配合版本约束使用；它不是独立语法糖，而是告诉 Composer：“把某个包的某个版本，当成另一个版本来满足约束”。比如你想让 vendor/package 的 dev-main 分支表现得像 2.0.0，就得这么写：
-
"vendor/package": "dev-main as 2.0.0"—— 这是唯一合法格式，中间不能有空格以外的字符 - 不能写成
"vendor/package": "dev-main as ^2.0"，as右侧必须是精确版本号（如2.0.0、1.5.3），不支持范围 - 如果该包本身 composer.json 里没声明
"version": "dev-main"或没打对应 tag，Composer 会忽略这个 alias，不会报错但也不生效
alias 和 repositories.package 内联包一起用的陷阱
alias 本身不触发下载或解析，它只在依赖求解阶段改写“版本匹配逻辑”；但如果你同时在 repositories 里用 type: package 声明了同一个包，就容易出问题：
- Composer 会先加载
repositories中的 package 定义，把它当真实包处理；此时再写"vendor/package": "dev-main as 2.0.0"，实际匹配的是你手动定义的那个package对象里的version字段，不是 VCS 分支的真实状态 - 常见错误：你在
package里写"version": "1.0.0"，又在require里写"vendor/package": "dev-main as 2.0.0"，结果 Composer 报Conclusion: don't install vendor/package 1.0.0—— 因为它发现你声明的包只有1.0.0，根本不存在2.0.0这个“别名目标” - 正确做法：要么只用 alias + VCS 仓库（删掉
repositories.package），要么在package定义里直接把version改成你要 alias 成的那个值（如"version": "2.0.0"）
alias 在 composer.lock 里存的是什么
composer.lock 不记录 alias 本身，只记录 alias “落地后”的实际版本。比如你写 "vendor/package": "dev-main as 2.0.0"，而 dev-main 当前 commit 是 abc123，那么 lock 文件里存的是：
"vendor/package": {
"version": "2.0.0",
"source": {
"type": "git",
"url": "...",
"reference": "abc123"
}
}
这意味着：
- 别人
composer install时，完全不知道你用了 alias，只看到安装了2.0.0版本 - 如果你删了 alias 改成
"vendor/package": "^2.0"，下次composer update可能拉到真正的2.0.1，和 lock 里存的2.0.0不一致 → 导致 CI 环境行为漂移 - alias 是一次性求解上下文，不参与后续版本比较；它不改变包自身的
require列表，也不影响 autoload 映射生成
为什么 composer why 不显示 alias 来源
composer why 查的是已安装包的依赖链，而 alias 在解析完成后就“消失”了——它只是求解器内部的一次性映射，不产生新包、不注册新关系。所以：
- 运行
composer why vendor/package，只会显示谁 require 了这个包，不会提一句“你是被 as 出来的” - 如果 alias 导致某包被意外满足（比如本该失败的约束因 alias 成立），你得靠
composer update --dry-run -v最后几行看求解路径，才能发现 alias 实际生效的位置 - alias 的调试成本高，它不像
conflict或replace那样留下痕迹；一旦用错，问题往往出现在运行时 Class not found 或方法不存在，而不是安装阶段报错
