Composer 2.0 起官方永久移除 SVN 支持，No driver found 错误表明其根本不识别 SVN URL；合法 repositories.type 仅含 git、hg、package、path、artifact，不包括 svn 或 vcs+SVN；唯一可行方案是改用 package（ZIP 归档）、path 或 artifact 类型手动集成。
Composer 不支持 SVN 仓库——这是当前（2026 年）的确定事实，不是配置问题，也不是环境缺失，而是官方在 Composer 2.0 中永久移除了 SVN 驱动。你看到的“支持 SVN”的文档，基本都来自 Composer 1.x 时代，已失效。
执行 composer install 报 No driver found 怎么办
这是最典型的症状，错误信息类似：
[RuntimeException] No driver found to handle VCS repository https://svn.example.com/repo/trunk
说明 Composer 根本没尝试连接 SVN，连认证或网络环节都没走到——它直接拒绝识别该 URL 为合法 VCS 源。
-
type: "vcs"+svn://或https://.../svn/...配置在composer.json中，现在纯属无效 - 降级到
Composer 1.10也仅能跑通极简场景（无认证、单 trunk、无子目录），且 PHP 8+ 和现代 cURL 策略下大概率失败 - 系统装了
svn命令也没用，Composer 2.x 根本不调用它
repositories.type 白名单里根本没有 svn
Composer 对 repositories 的 type 字段有硬编码白名单，合法值只有：
-
"git"（含 GitHub/GitLab 自动识别） -
"hg"（Mercurial） -
"package"（手动定义归档包） -
"path"（本地路径） -
"artifact"（离线 ZIP/TAR 文件）
注意："svn" 不在其中；"vcs" 类型虽存在，但它只匹配 git、hg、fossil 协议，不包括 SVN。写 "type": "vcs" + SVN URL，等同于写错类型。
想用 SVN 上的代码，唯一可行路径是绕过 VCS 自动拉取
必须放弃“自动检出 trunk/标签”这类 Git 式体验，改用静态交付方式：
-
用
package类型 + ZIP 归档：确保 SVN 服务支持?format=zip（如 VisualSVN Server 默认开启），然后在repositories中声明："dist": { "url": "https://svn.example.com/repo/trunk/?format=zip", "type": "zip" } -
用
path类型：先svn export到本地目录，再通过相对路径引用，例如：{"type": "path", "url": "../svn-exported-component"} -
用
artifact类型：把svn export打包成.tar.gz，放内网 HTTP 服务器或本地文件系统，再配{"type": "artifact", "url": "http://intranet/artifacts/"}
所有这些方式，都要求你手动保证 composer.json 在归档根目录，并且 autoload 路径与解压后结构一致——没有自动映射，也没有分支切换。
为什么不能简单加个驱动或插件恢复 SVN 支持
这不是功能开关问题，而是架构层面的放弃：
- SVN 缺乏 commit-hash 锁定能力，
installed.json无法生成可复现的安装记录 - 没有标准的元数据发现机制，Composer 无法从
trunk/或tags/下可靠定位composer.json - Subversion 官方已停止维护主流客户端（如命令行工具长期不更新），生态断层加剧
哪怕你找到某个第三方驱动，它也无法通过 Composer 2.x 的 RepositoryManager 校验流程，更不会被 composer validate 接受。
实际落地时，最容易被忽略的是：ZIP 归档链接必须能被 curl -I 直接返回 200 OK 和正确的 Content-Type，且解压后目录结构必须和 autoload 中的 psr-4 前缀严格对齐——差一个 src/ 层级，就会 autoload 失败，而错误提示往往只显示“Class not found”，根本不会指向 ZIP 结构问题。
