require字段只放运行时真正执行的代码依赖，即PHP进程启动后业务逻辑中必定new、use或include的类所在包；写错会导致线上Class not found且无明确堆栈。
require字段只放运行时真正执行的代码依赖
require不是“我将来可能用到的包”，而是“PHP进程启动后、业务逻辑跑起来时，一定会new、use或include的类所在的包”。写错位置，线上直接Class not found，连错误堆栈都找不到源头。
常见误判场景：
- 把
doctrine/doctrine-bundle放require-dev：它在容器构建阶段就被注册，--no-dev后整个 Doctrine 服务不可用，但报错是Service "doctrine.dbal.default_connection" not found，和依赖位置毫无关联 - 只用了
Illuminate\Support\Str::slug()，却没把illuminate/support加进require：Laravel 的工具类是独立发布的，不依赖框架主体，漏写就会Class 'Illuminate\Support\Str' not found - 把
phpunit/phpunit写进require：它只在vendor/bin/phpunit被调用一次，PHP 运行时不会加载它的任何类——但它会被部署到生产环境，白占磁盘，还可能因扩展缺失导致composer install失败
版本约束写错，不是装不上，而是装错
Composer 不会因为版本写错就报错退出，它会安静地拉一个你根本没想过的版本。问题往往在线上才爆发：行为不一致、方法不存在、返回类型突变。
"guzzlehttp/guzzle": "^7.0" 是安全选择，允许 7.0.0 到 7.999.999；而 "guzzlehttp/guzzle": "7.*" 表面一样，实际更易升到带破坏性 patch 的版本（比如某次7.5.1悄悄改了RequestOptions::JSON的默认行为）。
必须避开的写法：
-
"monolog/monolog": "2.12"：要求严格等于2.12.0，但 Packagist 上没有这个 exact 版本，安装直接失败 -
"laravel/framework": "dev-main"：开发分支无稳定性保证，CI 构建可能通过，线上却因命名空间变更崩溃 -
"ext-gd": "*"：扩展不是包，不能写进require，应检查php -m或在部署脚本中确认系统已装php-gd
查真实可用版本，别猜：composer show guzzlehttp/guzzle --all。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
require变动后，autoload不会自动更新
执行composer require guzzlehttp/guzzle，只是把包下载进vendor/并写进composer.json和composer.lock。你的use GuzzleHttp\Client;依然会报错——因为vendor/autoload.php里还没注册它的 PSR-4 映射。
触发 autoload 更新的唯一方式是：composer dump-autoload。这个命令常被跳过，尤其当你：
- 手动改了
composer.json里的autoload段（比如新增了一个psr-4命名空间），但没运行dump-autoload - 用了
--classmap-authoritative参数生成 autoload，却忘了新增路径不在 classmap 范围内 - 在 CI 中执行
composer install --no-dev后，没补上dump-autoload，导致新包类无法加载
注意：composer require本身会触发一次dump-autoload，但仅限于它自己引入的包；如果你同时改了项目自身的 autoload 配置，仍需手动补上。
require和require-dev混用时，autoload行为最隐蔽
Composer 生成的autoload.php会合并require和require-dev中所有包的自动加载规则，但--no-dev安装后，require-dev里的包物理上根本不存在于vendor/。这时如果代码里不小心use PhpParser\Node\Stmt（来自nikic/php-parser，常被放require-dev），就会在生产环境直接Class not found，而本地开发一切正常。
排查这类问题的关键点：
- 检查
composer show | grep php-parser输出是否含required by指向你项目——如果有，说明它被误写进了require - 上线前运行
composer install --no-dev && php -d display_errors=1 -d error_reporting=-1 -r "require 'vendor/autoload.php'; new PhpParser\Node\Stmt();"，能提前暴露 autoload 断层 -
require-dev包的类，永远不要出现在控制器、中间件、命令等主流程中；它们只该出现在tests/、scripts/或phpstan.neon这类配置文件里
最复杂的不是语法，而是判断“这段代码到底会不会在生产环境执行”。每次加依赖前，盯着那行use多看两秒，比事后翻三天日志更省时间。
