composer 中 "dev-branch as 2.0.0" 仅在 repositories 的 package 类型中合法，需严格匹配 name、version（含空格）、dist.url 和 autoload；镜像源与 alias 无关，生效须执行 composer update 并验证 versions 输出。
require里写"dev-branch as 2.0.0"会直接报错
这不是语法错误，而是根本不符合 Composer 的解析规则。composer require 或 require 字段中直接写 "monolog/monolog": "dev-main as 2.0.0" 会导致 Invalid version string "dev-main as 2.0.0"。Composer 只接受标准版本约束（如 ^2.0、dev-main、=1.2.3），as 不是版本语法的一部分，它只在特定上下文中被识别。
repositories 中 package 类型才支持 as 别名
真正能用 as 的地方，是 composer.json 的 repositories 配置里，且必须是 "type": "package"（不是 vcs，也不是空配置）。这个别名本质是“伪造一个包”，让 Composer 把某个真实源当成另一个版本来解析。
-
name必须和require中的包名完全一致（大小写敏感） -
version字段值必须是"dev-main as 2.0.0"格式：前后空格不能少，右侧必须是合法语义化版本（2.0❌，2.0.0✅） -
dist.url必须指向 zip/tar 归档地址（不是 Git URL），且该归档必须可公开访问并含有效composer.json - 必须同时定义
autoload规则，否则类加载会失败——alias 不继承原包 autoload
镜像源配置和 alias 完全无关
执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/ 只是换 HTTP 请求目标，不触发任何 alias 逻辑。镜像源不做版本映射、不改元数据、不解析 as。你看到的所谓“镜像别名”全是误传。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 所有镜像行为都在网络层，Composer 仍按原始包名 + 版本去查
-
extra.branch-alias是原包作者写的，只对 VCS 仓库生效，且 Composer 2.0+ 已废弃该字段 - 即使原包写了
"dev-main": "3.0.x-dev"，镜像源也只会原样转发，不会帮你做映射
alias 生效前必须跑 composer update
composer install 从 composer.lock 读版本，完全忽略新写的 alias。想让它起作用，必须触发依赖重解析：
- 运行
composer update vendor/name（指定包名最安全） - 或
composer update --dry-run先确认是否命中你写的别名版本 - 检查
composer show vendor/name输出里的versions行：如果显示* 2.0.0而实际代码来自dev-main，说明 alias 成功 - 若仍显示
dev-main，说明没被识别——常见原因是repositories里漏了version字段，或name拼写不一致
alias 是个高危映射操作：它只骗过版本解析器，不改代码、不补方法、不处理命名空间冲突。最容易被忽略的是 autoload 配置必须手动复制，否则 Class not found 错误不会告诉你是因为 alias 没配 autoload。
