Composer 不存在真正的“安装别名”，所谓 alias 实质是通过 repositories（type: package）精确接管包源或 replace 声明替代依赖，二者均需严格匹配 name、version 和 dist 结构。
Composer 不支持直接通过 composer.json 或命令行设置“包的安装别名”——所谓“别名”实际是通过 replace + provide + repositories 组合实现的伪别名，本质是让 Composer 认为某个包“替代”或“提供”了另一个包。真正在用时，容易误以为能像 npm 的 alias 那样自由映射路径或名称，结果报 Package not found 或依赖解析失败。
什么是 composer alias？它根本不存在
Composer 官方没有 alias 字段或配置项。社区常说的“alias”通常指以下两种场景之一：
- 想把
vendor/author/original-package在代码里用use MyAliasClass引入（这是 autoload 别名，和安装无关） - 想让
composer require some/package实际安装你自己的 fork 或镜像版本（这才是“安装别名”的真实需求）
后者才是本问题的核心：**如何让 Composer 在声明依赖时，把某个包名“指向”你指定的源**。
用 repositories + package type 实现“安装别名”
最可靠的方式是通过 repositories 声明一个 package 类型仓库，手动定义目标包的元信息，并将 dist.url 指向你的代码地址。这样 composer require vendor/name 就会拉取你指定的内容，而非 Packagist 上的原包。
关键点：
-
type必须为package（不是vcs，否则无法覆盖已存在包名） -
name必须与你要“别名”的包名完全一致（如monolog/monolog） -
version必须精确匹配（如3.0.0），或使用dev-main等开发版标识 -
dist.url要可访问，且压缩包结构需符合 Composer 规范（含正确composer.json）
{
"repositories": [
{
"type": "package",
"package": {
"name": "monolog/monolog",
"version": "3.0.0",
"dist": {
"url": "https://example.com/monolog-3.0.0.zip",
"type": "zip"
},
"autoload": {
"psr-4": { "Monolog\": "src/" }
}
}
}
],
"require": {
"monolog/monolog": "3.0.0"
}
}
用 replace + 自定义包名模拟别名（慎用）
如果你控制着被替换包的源码，可在其 composer.json 中加 replace，声明它“替代”另一个包。然后在主项目中 require 该自定义包，Composer 会认为已满足被替代包的依赖。
例如：你维护 myorg/monolog-fork，想让它替代 monolog/monolog：
{
"name": "myorg/monolog-fork",
"replace": {
"monolog/monolog": "*"
}
}
主项目中：
{
"require": {
"myorg/monolog-fork": "^1.0"
}
}
⚠️ 注意：
-
replace不会自动重写命名空间或类加载路径 - 若原包被其他依赖显式 require，而你的包未声明
provide或版本不兼容，仍可能触发冲突 - 升级时容易漏掉
replace版本约束，导致意外覆盖
autoload 中的 class alias 是唯一真正叫 alias 的地方
Composer 支持在 autoload.classmap 或 autoload.files 中做类级别别名，但这仅影响自动加载，不改变包安装行为：
{
"autoload": {
"classmap": ["src/"],
"files": ["src/MyAlias.php"]
}
}
其中 MyAlias.php 可以写：
<?php
class_alias('Original\Class', 'My\Alias\Class');
这种 alias 仅在运行时生效，和 composer install 无关，也解决不了“安装时换源”的问题。
真正要实现“安装别名”，核心只有两条路：用 repositories.type = package 精确接管特定包的安装源，或用 replace + 独立包发布来间接满足依赖。前者更可控，后者更适合长期 fork 维护；但无论哪种，都绕不开对 name、version、dist 三者的严格匹配——少一个字段，Composer 就会回退到默认源并报错。
