Composer 不校验运行时请求数据，只检查依赖漏洞；请求校验必须由应用代码（如 Laravel validate、respect/validation 或 filter_var）在服务端执行，且需防绕过。
composer 本身**不处理运行时请求数据校验**，它不是 Web 框架或验证库，也不介入 HTTP 请求、表单提交或 API 参数解析。你看到的“安全校验”混淆了两个层面：**依赖供应链安全**（composer 职责）和 **应用层数据校验**（PHP 应用逻辑职责）。
下面直接说清楚怎么做、为什么、容易踩什么坑。
composer audit 不校验请求数据，只查依赖漏洞
composer audit 扫描的是 composer.lock 中记录的包版本是否出现在 Packagist 安全公告库（Security Advisory Database）里。它不会读取你的 $_POST、$_GET 或 JSON body，也不会检查用户提交的邮箱格式、手机号长度、SQL 注入特征。
- 常见错误现象：在 CI 中跑
composer audit后以为“安全过关”，结果上线当天被参数注入打穿 - 本质原因：把“依赖有没有已知 CVE”等同于“我的代码接不接受恶意输入”
- 正确做法：把
composer audit当作**基础设施层守门员**，而请求校验必须由应用代码或框架完成
PHP 应用中真正做请求数据校验的典型方式
你需要在控制器、中间件或服务层手动或借助工具校验。主流方案有：
- Laravel：
validate()方法或FormRequest类，自动绑定规则并返回 422 - Symfony：
Validator组件 + 注解/PHP 属性，配合assert约束 - 轻量级：
respect/validation包，支持链式写法如V::email()->noWhitespace()->validate($input) - 原生 PHP：用
filter_var()（如filter_var($email, FILTER_VALIDATE_EMAIL)）+ 正则 +is_numeric()等组合
注意：respect/validation 是一个 Composer 包，但它的运行时行为与 composer 命令无关——安装后你得在代码里调用它。
为什么有人误以为 composer 能校验请求？
混淆通常来自三处：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 文档里出现“security”字眼（如
composer security:check），但该命令只是audit的别名，仍只读composer.lock - 某些旧教程把
php-security-checker（已停更）和composer功能混讲，其实它是独立 PHAR 工具 - 部署脚本里写了
composer install && php artisan validate:requests，让人误以为后半段是 composer 干的
真正的请求校验永远发生在 PHP 执行阶段，不是 composer install 阶段。锁死依赖版本（如 "symfony/http-foundation": "6.4.10"）能防止底层 Request 类出漏洞，但不能替代你写 if (!is_email($request->get('email'))) { ... }。
最容易被忽略的校验盲区
不是“有没有校验”，而是“校验有没有被绕过”：
- 前端 JS 校验被禁用后，后端没重做——所有校验必须服务端执行
- API 接口用
application/json，但代码里直接json_decode(file_get_contents('php://input'))后不做类型断言，导致int被传成string引发逻辑错位 - 上传文件字段（
$_FILES）只校验扩展名，不校验 MIME type 或文件头，被传入伪装的 WebShell - 使用
parse_str()或extract()处理未过滤的查询参数，造成变量覆盖
这些点，composer 一个都拦不住。它管的是“你用的轮子安不安全”，不是“你怎么踩油门”。
