Composer 自 2.0 起彻底移除对 SVN 的原生支持，不再识别 svn 协议和 VCS 驱动；若 composer.json 中配置了 SVN 地址，需改用 package、path 或 artifact 类型手动引入 ZIP 归档或本地代码。
Composer 不支持直接从 SVN 仓库安装包，官方早已移除对 Subversion 的原生支持（自 Composer 2.0 起彻底废弃 svn 协议和 subversion VCS 驱动）。如果你看到旧教程说“配置 SVN 源”，那基本是过时信息或混淆了概念。
为什么 composer install 会报 Could not fetch packages from svn
这是典型的版本升级后遗留问题。Composer 1.x 曾通过 subversion 驱动支持 SVN，但该驱动在 2.0 中被完全删除；即使你手动装回旧驱动，也会因 PHP 8+、cURL 策略或 SVN 客户端缺失而失败。
- 错误现象：
Failed to clone https://xxx/svn/trunk via https, ssh protocols, aborting.或Package type 'package' does not support installation - 根本原因：Composer 只认
git、hg（Mercurial）、zip、dist四类源，SVN 不在其中 - 真实场景：你可能在维护一个老项目，其
composer.json里写了"type": "vcs"+"url": "https://svn.example.com/repo"—— 这段现在纯属无效配置
替代方案：用 package 类型手动定义 SVN 包
如果必须用 SVN 上的某段代码（比如内部未迁移到 Git 的组件），唯一可行路径是绕过 VCS 自动拉取，改用静态包声明 + 手动下载归档。
- 把 SVN 地址转为可下载的 ZIP 归档链接（如
https://svn.example.com/repo/trunk/?format=zip，需 SVN 服务器开启此功能） - 在
composer.json中用package类型硬编码该包：
{
"repositories": [
{
"type": "package",
"package": {
"name": "vendor/svn-component",
"version": "dev-trunk",
"dist": {
"url": "https://svn.example.com/repo/trunk/?format=zip",
"type": "zip"
},
"autoload": { "psr-4": { "Vendor\\SvnComponent\\": "src/" } }
}
}
],
"require": {
"vendor/svn-component": "dev-trunk"
}
}
注意：dist.url 必须指向 ZIP（不能是 SVN URL），且该 ZIP 解压后结构要匹配 autoload 路径。
更现实的做法：别碰 SVN 源，改用 path 或 artifact
生产环境强烈建议避开所有 SVN 直连逻辑。以下两种方式更稳定、可审计、不依赖 SVN 服务可用性：
-
path类型：把 SVN 导出的代码放在本地目录，用相对路径引用 -
artifact类型：提前用svn export打包成 ZIP/TAR，放内网 HTTP 服务器或本地文件系统，再配置为 artifact 源
例如，在 composer.json 中添加：
"repositories": [
{
"type": "artifact",
"url": "./artifacts/"
}
]
然后把导出的 my-svn-pkg-1.0.0.zip 放进 ./artifacts/ 目录即可。Composer 会自动识别 ZIP 内的 composer.json 并加载。
真正卡住人的往往不是“怎么配 SVN”，而是没意识到 Composer 已经不认它了。最省事的解法，是让 SVN 仓库负责人导出一次 trunk，打个 ZIP 丢进私有 Packagist 或 artifact 目录——剩下的，Composer 就完全照常工作。
