保障代码纯洁：通过Composer Exclude Files剔除无关测试数据

保障代码纯洁：通过Composer Exclude Files剔除无关测试数据

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

先说一个核心事实：Composer本身并没有提供一种配置选项，能让你在composer install或composer update之后，直接阻止某些文件（比如测试数据、fixtures、.env.example等）被写入vendor目录或项目根目录。所有关于“排除文件”的需求，本质上都需要借助外部机制，配合Composer自身的生命周期事件来实现。如果处理不当，很容易导致误删、漏删，甚至破坏整个项目依赖的可复现性，那可就得不偿失了。

为什么composer.json里的exclude-from-classmap不起作用？

很多人第一个想到的就是它，但这里有个关键误解。这个配置项仅仅作用于自动加载器的生成过程，也就是控制vendor/autoload.php在构建类映射表时跳过哪些路径。它完全不会干涉文件是否被下载、解压或复制到磁盘上。换句话说，就算你在配置里写了"tests/": "exclude-from-classmap"，那个完整的vendor/some/package/tests/目录依然会安安静静地躺在那里。

• 它的影响范围仅限于vendor/composer/autoload_classmap.php这个文件的内容，对文件系统本身毫无触动。
• 对于那些不符合PSR-0/4标准的资源文件（比如JSON格式的测试数据、SQL转储文件、.md文档），它更是完全无效。
• 更要命的是，如果第三方包在它的install阶段执行了脚本（例如post-install-cmd），那么这些“本该被排除”的文件可能已经被读取或处理过了，事后清理为时已晚。

真正可行的剔除方案：巧用scripts钩子配合命令

目前最可控、也最透明的方法，是利用Composer的脚本钩子，在安装流程结束后手动进行清理。这在CI/CD环境或者需要极致优化部署体积的场景下尤其有用。

• 在你的项目composer.json文件的"scripts"部分添加类似下面的命令：

  "post-install-cmd": [
    "find vendor/ -name 'tests' -type d -prune -exec rm -rf {} +",
    "find vendor/ -name 'fixtures' -type d -prune -exec rm -rf {} +",
    "find vendor/ -name '*.md' -type f -delete"
  ]

• 这里需要注意执行顺序：post-install-cmd是在vendor/目录所有内容都解压完毕之后才运行的；为了保险起见，也可以在post-update-cmd里加上同样的逻辑。
• 在Linux或macOS下，使用find ... -delete通常效率更高。但如果你的开发环境是Windows，可能需要将其替换为PowerShell命令或forfiles，否则会报错。
• 切记，不要图省事使用rm -rf vendor/**/tests这种写法。不同shell环境下，通配符（glob）的展开行为可能不一致，而find命令的路径匹配方式则要可靠得多。

更安全、更优雅的替代方案：从源头控制打包内容

如果你能控制被依赖的包本身（比如公司内部的私有组件库），那么有一个更治本的方法：从源头打包时就排除无关文件，而不是让下游每个项目都去清理。

• 在需要发布的那个包的composer.json中，配置archive选项：

  "archive": {
    "exclude": ["/tests", "/fixtures", "/.env.example", "/CHANGELOG.md"]
  }

• 配置好后，使用composer archive命令打包，并将生成的ZIP文件发布到你的私有仓库（比如Satis或私有的Packagist）。
• 这样一来，下游项目执行composer install时，拉取到的ZIP包天生就不包含那些被排除的路径，彻底省去了额外清理的步骤。
• 需要留意的是，archive.exclude是Composer 2.2+版本才支持的特性，并且它只对通过composer archive生成的ZIP包生效。如果你的安装源是git仓库，这个配置是不起作用的。

说到底，真正的难点往往不在于“怎么删”，而在于“判断哪些能删”。有些包会把stubs/目录用作代码生成模板，有些包的examples/里藏着运行时必须加载的配置片段——对于这类目录，绝对不能进行无差别匹配删除。一个稳妥的建议是：先用composer show -s vendor/package命令查看包的源码地址，然后人工确认一下目标目录的实际用途。这比盲目地写一堆排除规则，要安全得多。