Composer 不校验业务数据，只管理依赖；真正数据验证需在 CI 中调用 PHP 验证逻辑（如 Laravel validating 包、PHPUnit 断言），并通过 composer.json scripts 定义命令统一启动，确保 require-dev 中的验证依赖被正确安装。
Composer 本身不校验业务数据，它只管理依赖；所谓“自动校验数据”在 CI 中实际是误用概念——你真正需要的是在 CI 流程里调用 PHP 验证逻辑（比如 Laravel 的 validating 包、自定义验证器或 PHPUnit 断言），而 Composer 只负责把它们装好、跑起来。
CI 中执行数据验证脚本必须靠 composer run 或直接调用命令
Composer 不解析你的数据库字段或 API 返回值，但它能帮你标准化启动验证流程：
- 在
composer.json的scripts里定义验证入口，例如："scripts": { "validate:api": "php scripts/validate-api-response.php", "validate:models": "php artisan validate:all-models" } - CI 脚本中统一用
composer run validate:api启动，避免硬编码路径或 PHP 版本差异 - 若验证脚本依赖第三方库（如
spatie/laravel-validation-rules），确保它们已声明在require-dev中，composer install --no-dev会跳过它们，导致运行时报Class not found
常见错误：把 composer validate 当成数据校验
composer validate 只检查 composer.json 文件格式和字段合法性（比如是否缺少 name、type 是否合法），和你的业务数据完全无关：
- 它不会读取
.env，不会连接数据库，也不会跑任何if ($user->email === null)判断 - CI 中误写
composer validate并以为“过了这关就数据安全了”，结果上线后才发现邮箱字段为空被存进去了 - 真正要做数据校验，得写测试用例：比如用 PHPUnit 断言
$response->assertJsonMissing(['email' => null])
结合 validating 包时 CI 必须启用 --no-dev 以外的包
像 laravel-validation 或 validating 这类包通常放在 require-dev，但如果你在 CI 中运行模型保存前的验证（比如跑一遍 php artisan db:seed --force 并触发验证），就得让它们可用：
- CI 安装命令不能加
--no-dev，否则ValidatingTrait类根本不存在 - 更稳妥的做法是把验证逻辑抽成独立命令（如
php artisan validate:seeds），并把它移入require，避免 CI 和生产环境行为割裂 - 注意
validating包默认在saved事件触发验证，而 CI 中的 seed 操作可能绕过 Eloquent 生命周期——得显式调用$model->validate()
真正的数据校验永远发生在 PHP 层，不是 Composer 层；CI 中唯一该由 Composer 做的事，就是确保验证所需的代码、类、配置都按预期装进了 vendor/，且没因 --no-dev 或缓存污染被悄悄跳过。
