Composer别名（as）仅在repositories的package类型中生效，require中直接写“dev-main as 2.0.0”会报Invalid version string错误；它只在依赖解析阶段伪装版本号，不解决API不兼容、类名冲突或autoload问题。
不能直接在 composer require 命令里用 as 语法写别名——这条命令会立刻报 Invalid version string 错误。 因为 as 不是 require 字段的合法版本格式，它只在 repositories 的 package 类型定义中被识别，且必须配合完整结构才生效。
为什么 composer require "monolog/monolog": "dev-main as 2.0.0" 一定失败
这条命令触发的是 root require 字段解析，而 Composer 在此处只接受标准版本约束（如 ^2.0、2.0.0、dev-main），as 会被直接拒掉。这不是手误，是设计限制。
-
as只在repositories的package条目内有效，且必须出现在version字段值中 - 漏掉
repositories配置，只改require行，等于没做任何事 - 即使你硬把
as塞进require，Composer 也不会报“不支持”，而是抛出模糊的Invalid version string，让人误以为是拼写问题
repositories + package 中 as 的正确写法
真正起效的配置必须包含三要素：严格匹配的 name、含 as 的 version、可拉取的 source.reference。缺一不可。
-
name必须和require中完全一致（大小写敏感），比如"monolog/monolog"，不能写成"Monolog/Monolog" -
version必须是"dev-main as 2.0.0"这种格式：as前后有空格，右侧是完整语义化版本（2.0不行，2.0.0才行） -
source.reference必须指向真实存在的分支或 commit ID，否则composer update会在Cloning into...卡住或报Failed to clone -
require字段仍写标准约束，例如"monolog/monolog": "^2.0"，让 Composer 主动去匹配你 alias 出来的那个“假版本”
as 别名生效但运行时报 Cannot declare class 怎么办
这说明 as 成功骗过了依赖解析，但没解决底层冲突——类加载路径和命名空间仍是原样，两个包若都注册了相同命名空间或同名类，就会炸。
-
as不修改autoload配置，package 类型定义中必须手动复制原包的autoload段，否则类根本不会被加载 - 如果两个包都声明
"psr-4": {"Monolog\": "src/"}，哪怕用了不同as版本，vendor/autoload.php仍会把两条路径都加进去 - 类名冲突无法靠
as规避，得走命名空间迁移、代理封装，或用replace彻底移除旧包 -
as后的版本号若与实际代码行为不一致（比如把symfony/console5.4.0 alias 成 3.4.49），运行时调用已移除方法会直接Fatal error
别名机制本质是“版本认知欺骗”，不是代码隔离工具。它最常被误用的地方，就是当成解决类冲突或 API 不兼容的捷径——而这恰恰是它完全不碰的领域。
