部署PHP项目时必须使用–no-dev参数，因为它确保仅安装require中的生产必要依赖，排除require-dev中的开发工具，从而减小体积、提升性能、降低安全风险，并避免意外调用；结合–optimize-autoloader可进一步优化类加载效率，是生产环境部署的标准操作。
在部署PHP项目时，–no-dev 参数对 Composer 来说非常关键。它直接影响生产环境的性能、安全性和稳定性。简单来说，加上这个参数能确保只安装项目运行所必需的依赖，排除开发阶段使用的工具和库。
什么是 –no-dev 参数？
Composer 默认会读取 composer.json 中的两个依赖部分：
- require：项目运行必须的库
- require-dev：仅用于开发和测试的工具，比如 phpunit、phpstan、faker 等
使用 –no-dev 选项后，Composer 只安装 require 中的依赖，完全跳过 require-dev。
为什么在部署时必须使用 –no-dev？
在生产环境中，我们追求的是轻量、高效和安全。不加 –no-dev 会带来几个明显问题：
- 增加部署体积：dev 依赖通常包含大量测试框架、静态分析工具等，这些文件在生产中毫无用处，却占用磁盘空间，拖慢部署速度。
- 潜在安全风险：某些 dev 工具（如调试器、代码生成器）如果暴露在生产环境，可能被攻击者利用。
- 影响性能：autoload 文件会更大，类加载更慢；一些 dev 包还可能注册不必要的服务或监听器。
- 避免意外调用：防止开发者误在生产代码中引用了 phpunit 或 mockery 这类测试库。
实际部署中的正确做法
无论你是用 CI/CD 脚本、手动部署还是使用 Laravel Forge 这类工具，都应该遵循以下命令：
composer install –no-dev –optimize-autoloader
其中：
- –no-dev：排除开发依赖
- –optimize-autoloader（或 -o）：生成更高效的类映射，提升性能
如果你在本地构建后再上传代码，也要确保构建过程使用了 –no-dev，否则上传的 vendor 目录可能包含多余文件。
常见误区
有些人认为“反正没调用就没事”，但生产环境应坚持最小化原则。即使 dev 包不会主动执行，它们依然：
- 占用内存和 inode
- 可能通过自动加载引入未知行为
- 增加攻击面（例如某些组件存在反序列化漏洞）
所以，不是“有没有用”，而是“该不该存在”。 基本上就这些。只要记住：部署 = 生产环境 = 只留必要的东西。–no-dev 不是可选项，而是标准操作。
以上就是Composer中的–no-dev参数在部署时有多重要的详细内容，更多请关注composer php laravel js json node 工具 为什么 php laravel composer json require