Composer报“Package not found”且Source 404，本质是原仓库被删、设私有或重命名，需手动通过repositories配置vcs源指定可用fork地址，并确保其composer.json中name字段与require完全一致。
没有“一键平移”这回事——所谓应急，本质是手动接管依赖源，且必须逐包确认、逐条配置。
为什么 composer install 报 “Package not found” 且 Source 404 就得立刻干预
这不是缓存问题，也不是网络抖动。Packagist 元数据里记录的 GitHub URL 已返回 404 或 410，说明原仓库被删、设私有、重命名，或作者遭勒索后下线代码库。Composer 拉不到源，composer install 必然卡死，CI 构建直接失败。
- 先验证：打开
https://packagist.org/packages/vendor/package-name，点 “Source” 链接看是否跳转到 404 页面 - 再确认：用
curl -I https://github.com/vendor/package-name检查真实状态码 - 别信 “别人 fork 了就行”——必须确保 fork 仓库里有完整
composer.json，且"name"字段与你require中完全一致（包括大小写和 vendor 名）
用 repositories + vcs 替换已失效包的实操要点
这是唯一能绕过 Packagist 源、让 Composer 接受替代 Git 地址的方式。不是加镜像，是硬指定新源头。
- 在项目根目录
composer.json的最外层加"repositories"数组，类型必须是"vcs"，不能是"package"（后者不支持分支切换） -
"url"填可访问的 Git 地址，比如"https://github.com/fork-user/package-name"；若只想要某个归档分支，加#legacy-fix后缀（如"https://github.com/fork-user/package-name#legacy-fix"） - 不要删掉原来的
require条目——Composer 会按name匹配，自动从新地址拉取 - 执行
composer update vendor/package-name，而非全量update，避免意外升级其他包
遇到 “required by another package” 别硬删，先理清依赖链
这不是报错，是 Composer 在拦你破坏依赖图。比如你想移除 guzzlehttp/guzzle，但 symfony/http-client 明确 require 它，命令就会中止并列出引用者。
- 运行
composer why guzzlehttp/guzzle查谁在用它 - 如果上游包（如
symfony/http-client）你也确实不用，就一起删：composer remove symfony/http-client guzzlehttp/guzzle - 若只是临时调试，可用
--no-update跳过实时重装，但之后必须跑composer update，否则composer.lock和 vendor 状态会脱节 - 绝对不要手动删
composer.json里的 require 行再跑install——锁文件哈希会不一致，CI 构建必然失败
删完包后必须人工扫三处残留，autoload 不会帮你擦屁股
composer remove 只管声明、vendor 目录、lock 文件和 autoload 映射。它不管你的 PHP 代码里还留着多少 use、new、Laravel 的 config/logging.php 配置，或者服务提供者注册。
- 全局搜
grep -r "Monolog\Logger" . --include="*.php"，确认没残留类引用 - 检查
config/、app/Providers/下是否有对应配置项或注册逻辑 - 删完立刻验证：
composer show monolog/monolog应报Package not found，ls vendor/monolog应提示No such file or directory
真正麻烦的从来不是删包，而是删完发现某个中间件里还 new 了一个被删掉的类——这种问题不会出现在 composer audit 或 composer validate 里，只能靠人眼扫。
