composer install 在生产环境报错“dev dependencies not found”是因为 composer.lock 记录了 require-dev 包，但部署时用了 –no-dev；必须确保 lock 文件已提交、生产使用 composer install –no-dev –optimize-autoloader，并统一 php 版本。
composer install 为什么在生产环境报错“dev dependencies not found”
因为 composer install 默认读取 composer.lock 安装，但若本地没提交 lock 文件、或 lock 文件里含 "require-dev" 的包（比如 phpunit、larastan），而生产环境又用了 --no-dev，就会导致依赖解析失败——不是缺包，是 lock 文件记录了 dev 包，却禁止安装它们。
- 确认本地已运行过
composer update或composer install，生成了最新composer.lock，且该文件已提交到 Git - 生产环境部署时，必须用
composer install --no-dev --optimize-autoloader，不能用composer update - 检查
composer.json中的"config": {"platform": {...}}是否锁定了与生产不一致的 PHP 版本（例如本地写"php": "8.2"，但服务器是 8.1）
vendor 目录能直接 rsync 过去吗
不能。看似省事，实则埋雷：不同架构（ARM/x86）、不同扩展（如 ext-redis 编译版本）、甚至不同 PHP 主版本（8.1 vs 8.2）下，vendor 里的二进制扩展或生成代码（如 Doctrine Proxy）可能无法加载或行为异常。
-
vendor是构建产物，不是可移植资产；它和当前 PHP 环境强绑定 - CI/CD 流程中，应在目标环境（或镜像）里执行
composer install，而非拷贝 - 若真要加速，可挂载 Composer 缓存目录（
~/.composer/cache）到 CI runner 或容器卷，复用已下载的 zip 包
如何确保生产环境只装 require，不装 require-dev
靠命令参数控制，不是靠删配置。删掉 composer.json 里的 require-dev 段再提交，等于放弃本地开发能力，属于反模式。
- 生产部署脚本里必须显式加
--no-dev，否则只要composer.lock里有 dev 包记录，install就会尝试装（即使composer.json已清空） -
--optimize-autoloader和--classmap-authoritative建议一起用，减少生产环境 autoloader 查找开销 - 验证是否生效：部署后执行
composer show，确认列表里没有phpunit、mockery等典型 dev 包
PHP 版本不一致导致 composer install 失败怎么办
Composer 会根据 composer.json 的 "platform" 配置或当前 PHP 版本做依赖约束校验。如果本地 PHP 8.2 允许装 symfony/console:^6.4，而生产是 8.0，该包可能因最低 PHP 要求为 8.1 而被拒绝。
- 最稳妥做法：生产环境 PHP 版本 ≥ 本地开发环境，至少主版本一致（如都用 8.1+）
- 临时兼容：在
composer.json的"config"下加"platform": {"php": "8.0"}，强制 Composer 按 8.0 解析依赖（但实际运行时仍需保证扩展可用） - 不要依赖
composer install --ignore-platform-reqs上线，它绕过所有平台检查，可能导致运行时报Function not found类错误
真正容易被忽略的是 lock 文件的生成环境——它不只是“记录版本”，还隐含了 PHP 版本、平台扩展、甚至 Composer 自身版本的约束。一次本地 composer update 可能悄悄把 ext-gd 的要求从 “*” 升级为 “>=8.1”，而你根本没注意。