Laravel如何优化Vendor目录体积？（生产环境建议）

生产环境Vendor目录优化实战指南

vendor目录为什么在生产环境还这么大？

这事儿其实挺常见的。你可能会纳闷，明明只是装了些核心包，怎么vendor目录还是动辄几百兆？原因很简单：默认的composer install命令是个“全家桶”安装模式。它不仅会拉取项目运行必需的依赖，还会顺带把开发依赖、文档、测试文件，甚至那些未压缩的源码和示例目录（比如examples/或docs/）一并下载下来。而这些内容，在生产环境里压根用不上。

删掉 vendor 里所有没用的文件（最直接有效）

最立竿见影的方法，不是手动去vendor里挑挑拣拣，而是用好Composer自带的“生产环境三件套”参数：--no-dev --optimize-autoloader --apcu-autoloader。

• --no-dev：这是关键。它会直接跳过composer.json里require-dev部分定义的所有包，比如phpunit、mockery这类只在开发和测试阶段需要的工具。
• --optimize-autoloader：这个参数会生成一个扁平化的类映射文件（vendor/composer/autoload_classmap.php），让PHP可以直接根据映射查找类，避免了运行时反复遍历目录文件的开销。
• --apcu-autoloader：如果服务器环境是PHP 7.4+并且启用了APCu扩展，加上这个参数可以将类映射缓存到APCu中，进一步提升自动加载性能。

完整的部署命令就是：composer install --no-dev --optimize-autoloader --apcu-autoloader。

这里有个重要提醒：这个命令最好在一个干净的、没有vendor/目录的环境下执行。如果已经存在vendor目录，稳妥的做法是先rm -rf vendor/清除掉，再运行上述命令，确保从头开始构建一个纯净的生产依赖集。

排除特定目录或文件类型（针对顽固大包）

不过，即便用了“三件套”，有些“顽固”的包（例如symfony/console、lara vel/framework本身）还是会包含大量的.md文档、.xml配置文件以及完整的tests/测试目录。Composer默认不会处理这些。至于composer.json里的archive.excludes配置，那只是针对composer archive命令打包时用的，对安装过程无效。

那么，真正有效的办法是在composer install之后，再加一个清理步骤。可以写一个简单的Shell脚本，在部署流程中自动执行：

find vendor/ -name "*.md" -delete
find vendor/ -name "tests" -type d -prune -exec rm -rf {} +
find vendor/ -name "Tests" -type d -prune -exec rm -rf {} +
find vendor/ -name "example*" -type d -prune -exec rm -rf {} +

建议把这段清理逻辑集成到你的部署脚本或CI/CD流程中，而不是每次手动执行。操作时请注意，避免误删vendor/bin/下的必要可执行文件（不过，由于已经使用了--no-dev，像phpunit这样的开发工具通常已经被排除了，所以相对安全）。

用 .gitattributes 防止 vendor 被意外提交或打包

这一点虽然不直接减少服务器上的vendor体积，但对于维护代码库健康至关重要。很多团队习惯将vendor/目录提交到Git仓库，这会导致仓库体积恶性膨胀、CI/CD拉取代码变慢、版本对比（diff）混乱不堪。

一个优雅的解决方案是在项目根目录创建或编辑.gitattributes文件，加入一行：

vendor/** export-ignore

这行配置的作用是，当使用git archive命令打包源码，或者在GitHub/GitLab上下载项目的ZIP包时，会自动排除vendor目录。这从源头上避免了冗余文件被分发。结合前面的composer install --no-dev，能形成一个从开发到部署的完整优化链条。

最后，提一个容易踩的坑：Lara vel项目下的storage/logs/和bootstrap/cache/目录，有时会因为部署脚本的路径问题，被误当作vendor的一部分处理。请务必注意，这两个目录是应用运行时目录，不属于vendor依赖，清理时千万别手滑一起删掉了。