composer 不校验用户数据，只管理依赖和验证 composer.json；用户数据校验须由 php 服务端完成，可用 rakit/validation 等库增强，且必须在接收 $_post 后立即执行。
Composer 本身不处理用户提交的数据校验——它压根不碰运行时请求、表单、API 参数或任何 $_POST / $_GET 内容。它的职责仅限于依赖管理：解析 composer.json、下载包、生成自动加载器、校验包完整性。把 Composer 当成“PHP 表单验证器”是常见误解。
为什么 composer validate 不校验用户数据
composer validate 只检查 composer.json 文件本身的 JSON 语法和字段语义（如 name 格式、type 是否合法），完全不读取、不解析、不接触任何用户输入。它连 $_SERVER 都看不到，更别说 HTTP 请求体了。
- 它不运行 PHP 代码，不执行
filter_var()或正则表达式 - 它不访问数据库，无法做唯一性校验（比如用户名是否已存在）
- 它不读取
$_POST、$_FILES或 API 请求 payload - 所谓“严格校验”，在 Composer 语境里只指
--strict模式下把警告升级为错误（如缺description字段直接失败）
PHP 用户数据校验该用什么
真正负责用户输入校验的是 PHP 服务端逻辑。核心原则是：**永远不信任前端传来的任何东西，每个字段都必须重验**。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 基础类型与格式：用
filter_var($value, FILTER_VALIDATE_EMAIL)、filter_var($value, FILTER_VALIDATE_INT)等，快且安全 - 自定义规则：用
preg_match()，例如手机号/^1[3-9]\d{9}$/、密码强度/^(?=.*[a-zA-Z])(?=.*\d)[a-zA-Z\d]{8,}$/ - 业务逻辑：查数据库判断唯一性、比对时间范围、校验文件 MIME 类型（而非后缀）
- 防攻击：用
htmlspecialchars()输出前转义，用 PDO 预处理防止 SQL 注入
想用 Composer 生态提升验证体验？选对库就行
Composer 可以帮你装真正管用的验证库，而不是自己写一堆 if (empty()) 和 is_numeric()：
-
composer require rakit/validation：Laravel 风格语法，支持required|email|min:6|same:confirm_password链式规则，错误信息可定制 -
composer require phpexperts/datatype-validator：专注类型强校验，区分'1'（字符串）和1（整数），适合 API 接口契约校验 -
composer require w7/engine-validate：微擎生态常用，规则写法紧凑（如lengthbetween:6,16），适合 CMS 类项目
这些库通过 Composer 安装，但运行时完全独立于 Composer 命令——它们是 PHP 类，由你调用，处理的是真实请求数据。
最容易被忽略的一点
很多人把前端 required、pattern 当成防线，甚至跳过服务端校验。但浏览器限制可被绕过，cURL、Postman、禁用 JS 后直接发请求，所有前端验证形同虚设。真正的校验必须发生在 PHP 接收到 $_POST 的第一行逻辑里，且每项都应有明确的错误反馈路径——不是“验证失败”，而是“邮箱格式不正确”或“密码不能少于 8 位”。
