应通过 repositories 配置 type: "vcs" 或 "package" 指向可用 Git 仓库或本地路径，确保 url 可访问、composer.json 中 name 与 require 完全一致，并执行 composer update vendor/package；切勿盲目删 vendor 或改版本号。
Composer install 报错 “Package not found” 且提示源已删除
遇到这种报错，十有八九是某个依赖包在源头上出了问题——可能是作者从 Packagist 上移除了仓库，也可能是 GitHub 或 GitLab 上的项目被设为私有、改了名字，甚至彻底删除了。Composer 默认的工作方式，是从 Packagist 的元数据里获取包信息。一旦它缓存的包链接失效（比如原本指向的 https://github.com/xxx/old-package 返回了 404），那么无论是执行 composer install 还是 composer update，都会卡在“Package not found”或“Could not find package”这类错误上。这可不是清理本地缓存就能解决的，问题的根源在于源头已经不可达了。
这时候，先别急着去删除整个 vendor 目录，或者手动修改 composer.json 里的版本号。第一步，是确认这个包是真的“消失”了，还是仅仅换了身“马甲”：
- 打开这个包在 Packagist 的页面（格式通常是
https://packagist.org/packages/vendor/package-name），看看“Source”链接是否还能正常访问。 - 直接用
curl -I命令或者在浏览器里访问源码仓库的 URL，确认返回的状态码（404、410 或 403 是最常见的情况）。 - 去 GitHub 上搜一下，可以用
"package-name" archived:true这样的关键词，或者看看项目的 fork 网络里，有没有其他活跃的分支。
用 repository 替换原包源，指向可用 fork 或归档分支
Composer 提供了一个非常实用的功能：允许你在 composer.json 里直接指定一个替代的源码仓库，它的优先级会高于 Packagist。这里的关键，不是简单地添加一个镜像地址，而是明确告诉 Composer：“这个包，你别去 Packagist 找了，直接去我指定的这个 Git 地址拉取。”
具体操作时，有几个要点需要把握：
- 在
composer.json的根对象下，添加一个"repositories"数组，其类型（type）必须设置为"vcs"。 "url"字段填入一个可以正常访问的 Git 地址（GitHub、GitLab 或者自建的 Gitea 都可以），但必须确保这个仓库里包含有效的composer.json文件，并且文件里的"name"字段，必须与你项目中 require 的包名完全一致（包括 vendor 名称）。- 如果原包已被删除，但有社区的 fork 版本，优先选择 star 数高、最近还有提交记录的那个。如果只有归档的旧分支，可以用
#branch-name的格式来指定（例如：https://github.com/fork-user/package-name#legacy-fix）。 - 切记，不要删除原来
require里的条目——Composer 会自动根据包名进行匹配，并从你新指定的 repository 拉取代码。
下面是一个配置示例：
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/active-fork/package-name"
}
],
"require": {
"original-vendor/package-name": "^1.2"
}
}
手动克隆 + path repository：适合需本地调试或 patch 的场景
当你需要对代码进行修改、打补丁，或者目标仓库连一个可用的 fork 都找不到（只剩下本地的 zip 备份或旧版本），那么 path 类型的 repository 就是最直接、最可靠的兜底方案了。它让 Composer 直接把本地的一个文件夹当作包的来源，完全跳过网络请求。
采用这种方式，有几个硬性条件必须满足：
- 本地目录里必须包含一个有效的
composer.json文件，并且文件里的"name"和"version"字段，必须与项目require中声明的完全一致（"version"可以临时写成"dev-main"，同时需要在根composer.json中配置"minimum-stability": "dev"来配合）。 - 在
"repositories"配置中，url 需要填写绝对路径（Linux/macOS 用/home/user/pkg格式，Windows 用C:/path/to/pkg格式），不能使用相对路径。 - 执行更新时，建议使用
composer update original-vendor/package-name来单独更新这个包，而不是进行全量更新，以免意外影响到其他依赖。 - 这种方式通常不纳入项目的版本控制（除非你确实想把第三方代码塞进自己的仓库），它更适合用于临时修复问题，或者在 CI 环境中进行调试。
为什么不用 --ignore-platform-reqs 或 --no-scripts？
这里有个常见的误区：试图用 --ignore-platform-reqs 或 --no-scripts 这类参数来绕过错误。实际上，这两个参数解决的是“PHP 版本不兼容”或者“安装脚本执行失败”这类问题，对于“包根本不存在”这个源头性错误，它们是完全无效的。强行加上这些参数，只会把错误延迟到 autoload 阶段——表面上 vendor/autoload.php 可能生成成功了，但一到运行时就会抛出 Class not found 异常，因为相关的类文件压根就没有被下载下来。
真正应该关注的，是以下几个诊断命令的反馈：
composer show original-vendor/package-name是否能列出包的详细信息？composer why-not original-vendor/package-name:1.2.0是否提示了版本冲突？- 检查
cat vendor/composer/installed.json | grep package-name的输出是否为空？
这些信息比日志里泛泛的“failed to open dir”要准确得多。话说回来，很多时候问题并非出在“删库”本身，而是一些细节：比如分支名拼写错误、Git 协议权限没配置对（例如用了 git@ 开头但没配置 SSH key）、或者替代仓库里的 composer.json 缺少了关键的 "autoload" 配置段。这些细节，往往比问题本身更容易让人卡住。
