应通过 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”链接是否 404 - 用
curl -I或浏览器直接访问源仓库 URL，确认返回状态码（404 / 410 / 403 最常见） - 搜 GitHub，用关键词
"package-name" archived:true或查看 fork 网络，找活跃分支
用 repository 替换原包源，指向可用 fork 或归档分支
Composer 允许你在 composer.json 里硬编码一个替代源，优先级高于 Packagist。关键不是“加个镜像”，而是告诉 Composer：“这个包，别去 Packagist 找，去我指定的 Git 地址拿”。
操作要点：
- 在
composer.json根对象下添加"repositories"数组，类型必须为"vcs" -
"url"填可访问的 Git 地址（GitHub/GitLab/自建 Gitea 均可），确保该仓库包含composer.json且"name"字段与你项目中 require 的完全一致（包括 vendor 名） - 如果原包已删但有社区 fork，优先选 star 高、最近有 commit 的；若只有归档分支，用
#branch-name指定（如https://github.com/fork-user/package-name#legacy-fix） - 不要删掉原来的
require条目——Composer 会自动匹配 name 并从新 repository 拉取
示例片段：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
{
"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"配合"minimum-stability": "dev"） -
"repositories"中 url 填绝对路径（Linux/macOS 用/home/user/pkg，Windows 用C:/path/to/pkg），不能是相对路径 - 执行
composer update original-vendor/package-name，而非全量 update，避免误刷其他包 - 该方式不进 Git（除非你真想把第三方代码塞进自己仓库），适合临时修复或 CI 调试
为什么不用 --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" 段——这些细节比“删库”本身更容易卡住人。
