应先确认包是否被迁移或重命名，再通过VCS方式直连Git仓库安装，并锁定commit hash；长期需fork归档并替换命名空间。
Composer install 报错 “Package not found” 或 “Package has been deleted” 怎么办
遇到 composer install 失败并提示某个包“已被原作者删除”，通常不是网络或缓存问题，而是 Packagist 上该包的注册记录已被移除——哪怕 GitHub 仓库还存在。Packagist 不托管代码，只索引元数据；一旦作者主动 delist 或账号被封，packagist.org/packages/{vendor/name} 返回 404，Composer 就无法解析依赖。
确认包是否真的不可用，还是只是被重命名或迁移到新命名空间
先别急着换方案，很多“被删”其实是作者迁移导致的路径变更。比如 monolog/monolog 曾短暂从 Packagist 下架又恢复；更多情况是作者把 oldvendor/package 改成 newvendor/package，但旧 composer.json 还在引用老名。
- 打开浏览器访问
https://packagist.org/packages/{vendor}/{package}（把 {vendor}/{package} 替换成报错里的实际值），看是否 404 - 用
git log -S "{package}" -- composer.json查最近一次修改，确认是不是刚升级过依赖 - 搜 GitHub：直接输入包名，看是否有同名仓库，留意 README 是否提到“moved to xxx”或“replaced by yyy”
- 检查该包是否转为私有——有些开源项目后期闭源，仅保留 GitHub 公开，但不再提交到 Packagist
临时绕过 Packagist，用 VCS 方式直连 Git 仓库安装
只要源码还在 GitHub/GitLab 等平台可访问，就能跳过 Packagist，让 Composer 直接从 Git 拉取。关键在 repositories 配置，且必须指定 type: vcs 和正确 URL。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
在项目根目录的 composer.json 中添加：
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/author/repo-name"
}
]
}
-
url必须是可git clone的地址，支持 HTTPS 和 SSH；若仓库是私有，需提前配置 SSH key 或 GitHub token - 不需要手动写
require项——原有依赖声明保持不变，Composer 会自动匹配name字段（即author/repo-name） - 如果仓库的
composer.json里"name"和你 require 的不一致（比如写成了forked/repo-name），安装会失败；此时要么改 fork 的composer.json，要么用package类型手动定义元数据 - 执行
composer install --no-cache，避免本地缓存干扰
长期维护建议：锁定 commit hash，避免分支漂移风险
用 VCS 方式拉取时，默认走 master 或 main 分支，但作者可能随时 push 破坏性更新。生产环境必须锁定具体版本。
- 在
require中不写"^1.2"这类版本约束，改用"dev-main#abc1234"（Git commit hash）或"dev-master#v1.2.0"（带 tag 的 ref） - hash 必须是完整 40 位（Composer 会自动截断，但显式写全更稳妥），可用
git ls-remote https://github.com/author/repo-name | grep main获取最新 commit - 注意：使用 hash 后，
composer update不会自动升级，必须手动改 hash 并验证兼容性 - 如果该包已无维护，建议尽快 fork 并替换为自己的组织名（如
yourorg/repo-name），然后在repositories中指向你的 fork —— 否则下次作者删库就彻底断链
真正麻烦的不是“怎么装”，而是“谁来保证这个包未来三个月还能 git clone”。VCS 方式只是止血，归档、fork、替换命名空间，才是维稳的关键动作。
