--dev安装开发依赖，--no-dev仅安装生产依赖；本地开发使用--dev，生产环境用--no-dev以减小体积、提升安全；CI/CD中测试阶段用--dev，构建镜像时用--no-dev优化性能。
在使用 Composer 管理 PHP 项目依赖时，--dev 和 --no-dev 是两个常用选项，用于控制开发依赖的安装与加载。理解它们的切换方法和应用场景，有助于优化项目部署、提升性能并保障环境一致性。
什么是 --dev 和 --no-dev 模式
--dev 是 Composer 的默认行为，表示在执行 composer install 或 composer update 时，会安装 require 和 require-dev 中定义的所有包。这些 dev 包通常包括测试工具（如 phpunit）、代码规范检查（phpcs）、调试工具等。
--no-dev 则表示仅安装 require 中的生产依赖，忽略 require-dev 下的所有包。这在生产环境中非常关键，可以减少不必要的文件体积和潜在安全风险。
如何进行模式切换
切换这两种模式主要通过在命令行中添加对应参数实现：
- 安装所有依赖（包含开发依赖）：
composer install --dev - 仅安装生产依赖：
composer install --no-dev - 更新依赖时排除开发包：
composer update --no-dev
注意：若未指定 --no-dev，Composer 默认启用 --dev 模式。
典型应用场景解析
不同环境对依赖的需求不同，合理使用这两个模式能提升效率与安全性。
本地开发环境使用 --dev
开发者在本机构建项目时，需要运行测试、格式化代码或调试，因此必须安装开发依赖。此时应确保不加 --no-dev，让 Composer 自动加载 require-dev 中的工具。
生产环境部署使用 --no-dev
上线部署时，服务器不需要 PHPUnit 或 PHPStan 这类工具。使用 composer install --no-dev 可减少 vendor 目录大小，加快加载速度，并降低因多余组件引发的安全隐患。
CI/CD 流水线中的灵活应用
持续集成流程中，测试阶段需启用 --dev 来运行单元测试；而构建生产镜像（如 Docker）时，则应使用 --no-dev 确保镜像轻量化。例如：
- Dockerfile 示例片段：
RUN composer install --no-dev --optimize-autoloader - CI 脚本中运行测试：
composer install && vendor/bin/phpunit
注意事项与最佳实践
避免混淆环境配置。比如在生产环境误装 dev 依赖，可能引入非预期行为或暴露调试接口。
建议在项目文档中明确说明不同环境下使用的 Composer 命令，团队协作更顺畅。
可结合 composer dump-autoload --optimize 和 --classmap-authoritative 提升生产环境性能，尤其在禁用自动加载扫描时效果明显。
基本上就这些。掌握 --dev 与 --no-dev 的切换逻辑，能让你更精准地控制依赖范围，适应从开发到上线的全流程需求。
