composer 不支持运行时别名共存，其“alias”实为 provide 声明+conflict 约束的虚拟版本契约，仅影响依赖解析，不改变加载路径或运行时行为。

Composer 本身不支持“别名”来让同一包的多个主版本共存——这是个常见误解。所谓“alias”，在 Composer 语境里不是加载时的路径重写，而是 provide + conflict 构建的虚拟版本契约，只影响依赖解析阶段，不改变运行时行为。

Composer 的 “alias” 实际是 provide 声明，不是路径映射

你不能像 Webpack 那样写 resolve.alias 把 guzzlehttp/guzzle 指向两个不同目录。Composer 没有运行时模块加载控制权，它只管安装什么、装哪个版本、是否满足约束。所谓“别名”，本质是告诉 Composer：“当前已安装的 v8.4.5，对外宣称自己也提供 v7.99.99 这个版本”。

必须配合以下两点才有效：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• conflict 阻止旧版被拉入：比如 "guzzlehttp/guzzle": "
• provide 声明兼容性：比如 "guzzlehttp/guzzle": "7.4.5 as 7.99.99"（注意 as 左边是真实版本，右边是对外“冒充”的版本）
• 该声明仅对依赖求解器生效；你得确保 v8 真的兼容 v7 的公共 API（Guzzle 官方承诺客户端接口兼容，但内部类如 GuzzleHttp\Stream 已移除）

为什么不能用 repositories + package type 做“真别名”

有人尝试在 repositories 里加一个 type: "package" 来伪造一个 monolog/monolog 的 v2.10.0，再 require 它。这看似绕过冲突，但存在硬伤：

• Composer 不允许你把已安装的稳定包（如 v2.10.0）alias 成另一个主版本（如 v3.0.0），会直接报错“semantic version violation”
• 即使成功安装，所有 autoloader 都指向同一个命名空间 Monolog\，v2 和 v3 的类无法共存，运行时报 Cannot declare class Monolog\Logger
• 这种做法绕过了 Packagist 元数据校验，容易导致 autoload 错误或缺失 dist 资源

真正能缓解冲突的操作只有三类

别指望 alias 自动帮你选版本或隔离运行时——它只是求解器层面的“话术”。要落地，得结合具体场景选路：

• 若 A 包 require guzzlehttp/guzzle:^7.0，B 包 require ^8.0，而你已装 v8：用 provide + conflict 告诉 Composer “v8 就是 v7 的超集”，前提是确认 API 兼容
• 若冲突来自 dev 依赖（如 phpunit/phpunit 锁死 sebastian/exporter）：运行 composer why-not guzzlehttp/guzzle:^8.0，从输出最后一行（你的根 composer.json）往上逐级看谁在拦路
• 若想彻底隔离，只能封装：把某版本 Guzzle 封进独立私有包，用 autoload-psr4 映射到自定义命名空间（如 MyApp\GuzzleV7\），但这要改源码、维护成本高，非必要不推荐

最关键的细节常被忽略：provide 声明后，composer show --tree 里看到的仍是真实版本号，但 composer depends guzzlehttp/guzzle 会显示哪些包“依赖于你提供的 v7.99.99”——这个视图才是别名生效的唯一证据。