最稳妥的迁移方式是先手动删除 require-dev 中的包条目，再执行 composer require vendor/package --no-dev；该命令会自动将其加入 require 并移除 require-dev 中同名项，避免手动编辑引发 autoload 错误、版本冲突或 scripts 污染生产环境。
composer require 时加 --no-dev 是最直接的迁移方式
把一个原本在 require-dev 里的包（比如 phpunit/phpunit）移到 require，本质不是“移动”，而是重新声明依赖关系。最稳妥的做法是先删掉 dev 里的旧条目，再用 composer require 命令把它加进正式依赖里。
执行前确保当前目录有 composer.json，且已运行过 composer install 或 composer update：
- 运行
composer require vendor/package-name --no-dev，例如composer require monolog/monolog --no-dev - 这条命令会自动从
require-dev中移除同名包（如果存在），再写入require - 不加
--no-dev默认会写进require-dev，容易误操作 - 如果包已在
require-dev中但没被安装（比如刚改过composer.json没 run install），require --no-dev仍能正确识别并迁移
手动编辑 composer.json 容易漏掉 autoload 或版本冲突
有人会直接打开 composer.json 把包从 "require-dev" 剪切到 "require"，这看似快，但有三个隐藏风险：
-
autoload配置可能只在require-dev包中启用（比如某些测试工具的psr-4映射），移到require后若未同步调整，运行时类找不到 - 如果该包和已有
require中的其他包有版本约束冲突（如symfony/console ^5.4和^6.0并存），手动改完 JSON 不会触发依赖解析，composer install时直接报错 - 包的
scripts或extra字段（如phpstan的配置）可能被一并带过去，而这些本不该出现在生产环境
require-dev 包被 require 后，vendor/autoload.php 加载行为不变
Composer 的自动加载机制不区分 require 和 require-dev —— 只要包被安装，它的 autoload 规则就生效。所以迁移后代码里 use 或 new 该包的类，不会因位置变化出问题。
但要注意实际影响：
- 运行
composer install --no-dev时，这个包仍会被安装（因为它现在在require），而原来在require-dev时会被跳过 - 包体积变大、安全扫描范围扩大：原来只在开发机上存在的依赖，现在会随部署一起上线，需确认它是否真需要在运行时存在（比如
doctrine/orm是必须的，phpspec/phpspec就不该） - CI/CD 流水线中若用了
--no-dev，迁移后该包不再被跳过，可能暴露未处理的兼容性问题
检查是否真有必要迁移：dev-only 包误入 require 是常见隐患
有些包天生就不该进 require，比如 roave/security-advisories（纯 Composer 约束检查）、vimeo/psalm（静态分析）、laravel/pint（代码格式化）。它们只在开发阶段起作用，没有运行时价值。
判断依据很简单：
- 代码里有没有
new、use或call_user_func调用它的类或函数？ - 它是否提供运行时服务（如日志、HTTP 客户端、数据库抽象）？
- 它的
composer.json中type是不是library？如果是metapackage或tool，基本不用进require
强行把工具类包移到 require，只会让生产环境多装一堆无用代码，还可能引入意外的 autoloader 冲突或内存开销。
