composer 不支持 mercurial（hg）作为原生 vcs 类型，因其 vcsrepository::isurlsupported() 方法硬编码过滤 hg 协议，导致 type: "vcs" + hg url 静默失败；可行方案是改用 type: "package" 手动声明，并通过 dist.url 指向可下载归档。
Composer 本身不支持 Mercurial（hg）仓库作为原生 VCS 类型，composer.json 中的 repositories 配置仅接受 "type": "vcs"，且实际只识别 Git、SVN、GitHub、GitLab 等，**Mercurial 会被静默忽略或触发克隆失败**——这不是配置方式问题，而是底层依赖 composer/installers 和 composer/semver 未实现 hg 协议支持。
为什么 type: "vcs" + hg URL 总是失败
当你在 repositories 中写入类似这样的配置：
{
"repositories": [
{
"type": "vcs",
"url": "https://example.com/repo.hg"
}
]
}
Composer 会尝试调用系统 hg 命令，但实际流程中：
• composer install 不会主动检测本地是否安装 hg
• 即使已安装，composer 的 VcsRepository 类内部硬编码过滤了 hg 协议（见 src/Composer/Repository/Vcs/VcsRepository.php 的 isUrlSupported() 方法）
• 最终报错通常是 Could not fetch packages matching ... 或静默跳过该仓库
可行替代方案：用 package 类型手动声明
绕过 VCS 自动发现，把 hg 仓库当作“已知版本的静态包”来处理。你需要自己提供完整元信息：
- 确保你有该 hg 仓库的明确 revision ID（如
1a2b3c4d）或 tag（如v1.2.0） - 在
composer.json中以"type": "package"显式声明，并指定dist下载方式 -
dist.url必须指向一个可直接下载的归档链接（例如 Bitbucket 提供的/get/接口）
示例（适配 Bitbucket hg 仓库）：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
{
"repositories": [
{
"type": "package",
"package": {
"name": "vendor/package",
"version": "dev-main",
"dist": {
"url": "https://bitbucket.org/vendor/package/get/1a2b3c4d.tar.gz",
"type": "tar"
},
"autoload": {
"psr-4": { "Vendor\Package\": "src/" }
}
}
}
],
"require": {
"vendor/package": "dev-main"
}
}
注意：dist.url 必须能被 curl 或 Composer 内部 HTTP 客户端直接获取；Bitbucket 的 /get/{rev} 路径返回的是 tar.gz，所以 "type": "tar" 是必须的。
更现实的选择：转换为 Git 或发布到 Packagist
如果你能控制该 hg 仓库，以下路径更稳定、可维护性更高：
- 用
hg convert将仓库迁移到 Git（保留历史），然后托管到 GitHub/GitLab，再用标准"type": "vcs"引入 - 若该包是公共库，直接 push 到 Packagist.org —— Packagist 支持从 hg 仓库自动抓取（通过其后端的
hg clone），但前提是仓库公开且含合法composer.json - 若必须保留在私有 hg 服务器，考虑在 CI 中每次提交后自动生成并推送 ZIP 包到内部 HTTP 服务，再用
package+dist指向它
硬依赖本地 hg 命令 + Composer 组合，在现代 PHP 项目中几乎不可靠，因为 Composer 3+ 已进一步弱化对非 Git VCS 的测试覆盖。
真正卡住的地方往往不是语法，而是误以为 "type": "vcs" 是万能开关——它只对 Git/SVN 开箱即用，hg 需要你主动接管分发环节。
