inline alias 是通过 "package/name": "dev-main as 2.8.0" 将开发分支强制映射为指定语义化版本，使 Composer 能满足稳定版本约束；它不是注释，而是参与依赖解析的核心版本重映射机制。
Composer 本身不支持给依赖加“版本注释”，所谓“加注释”实际是误用术语——你真正需要的是 inline alias，也就是在 require 字段里用 as 关键字把一个开发分支映射成某个语义化版本号，让 Composer 能把它当作正式版来解析依赖。
inline alias 是什么，为什么不能写成注释？
inline alias 不是注释，而是强制版本重映射机制。Composer 解析依赖时严格比对版本约束（比如 ^2.8），而 dev-main 这类分支默认属于 dev 稳定性级别，不满足任何 stable 版本约束。只有通过 "package/name": "dev-main as 2.8.0" 这种写法，才能让 Composer 在内部把它当成 2.8.0 处理。
- 写成
// dev-main (WIP)或# test branch完全无效，Composer 会直接忽略这些字符 -
as右侧的版本号必须真实满足其他依赖的约束条件，例如不能用as 1.0.0去满足^2.5 - 如果目标分支没有打过 tag，又没配
as，composer update很可能跳过它或报could not be resolved
什么时候必须用 inline alias？
典型场景是测试未发布代码：PR 分支、fork 功能分支、主干临时修复。只要你的项目里其他地方写了类似 "some/package": "^3.2"，而你想装的却是 dev-fix-encoding，就必须加 as。
- GitHub PR 分支通常表现为
dev-pr-123，可写成"vendor/pkg": "dev-pr-123 as 3.2.1" - 如果你 fork 了包并推了新分支，且原包
composer.json没配extra.branch-alias，那就只能靠inline alias救急 - 配合
repositories使用时，as是唯一能让 Composer 接受该分支的方式，否则会提示version not found
as 后面的版本号怎么选才不翻车？
别乱填。这个版本号不是随便写的标签，它参与整个依赖图的语义化版本计算。填错会导致依赖冲突、升级失败，甚至装错其他包。
- 优先参考目标分支最近一次 tag 的版本，比如上个 tag 是
v3.2.0，就用as 3.2.0或as 3.2.1（补丁级递增） - 若分支明显是为下一个大版本准备的（如重构 API），可用
as 4.0.0-alpha，但要确保项目允许minimum-stability: alpha - 绝对不要用
as dev-main或as latest—— 这些不是合法版本字符串，Composer 会直接报错Invalid version string - 不确定时，先跑
composer depends vendor/pkg看谁在依赖它，再检查它们的约束范围
inline alias 和 branch-alias 有什么区别？
inline alias 是你在自己项目里写的临时映射；branch-alias 是被依赖包自己在 composer.json 的 extra 里声明的长期映射，只对 VCS 包生效，且必须是 dev- 开头的分支。
- 你改不了别人的
branch-alias，但你可以随时在自己项目里加inline alias -
branch-alias写在被依赖包里，例如"extra": {"branch-alias": {"dev-main": "3.x-dev"}}，这样别人就能用"vendor/pkg": "^3.0"直接装main分支 - 两者不互斥：如果被依赖包已声明
branch-alias，你再写inline alias，后者会覆盖前者 - 最易忽略的一点：
inline alias不会改变实际安装的代码来源，它只影响版本号解析 —— 代码还是从你repositories指向的地址拉的
