composer仅支持三类校验：validate（语法与语义）、verify-checksums（vendor文件完整性）、脚本集成外部工具（如phpcs）；启用完整字段校验须用composer validate --strict --no-check-publish，哈希校验需composer_experimental=1 composer verify-checksums --strict，且关键文件如autoload.php完全游离在校验体系外。
Composer 本身不提供“数据校验规则”这种抽象概念——它没有类似表单验证或 JSON Schema 那样的通用数据结构校验能力。你真正能配置的，只有三类校验行为：composer validate（校验 composer.json 语法与语义）、composer verify-checksums（校验 vendor/ 文件完整性）、以及通过脚本集成外部工具（如 phpcs）做代码风格检查。所谓“数据校验规则”，实际是这三者的组合使用场景。
composer validate 怎么启用完整字段合法性校验
默认 composer validate 只检查 JSON 语法和极少数硬性字段，大量拼写错误、废弃值、缺失必填项会被静默放过。必须加 --strict 才触发完整语义校验：
-
"autoloader": {}（应为"autoload"）→ 不加--strict完全不报错 -
"type": "libary"（拼错）或"minimum-stability": "dev-master"（已弃用）→ 只有--strict才失败 -
description字段缺失 → 默认仅警告，--strict下直接 exit 1 - CI 中务必固定用：
composer validate --strict --no-check-publish，跳过 Packagist 连通性检查，避免网络抖动中断流程
vendor 文件哈希校验为什么非得用 verify-checksums --strict
composer install 只在校验下载包解压前的 dist 哈希，而磁盘上真实文件可能已被篡改或污染。唯一能读取 vendor/ 实际字节并重算 SHA256 的命令是：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须前置环境变量：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict，否则命令不可见或仅警告 - 它跳过
type: "path"包和无dist.sha256字段的老包，不会报错，但容易漏检 - 不校验
vendor/composer/autoload_*.php等生成文件——这些文件被手动修改后，verify-checksums会失败（因为它们在vendor/目录下但无哈希记录） - 报
mismatch时不指明具体哪个文件出问题，需配合find vendor/<pkg> -type f -print0 | xargs -0 shasum -a 256</pkg>手动比对
怎么把 PHP 代码规范检查塞进 Composer 脚本
Composer 不校验代码逻辑，但可通过 scripts 集成 phpcs。关键不是装包，而是注册执行时机：
- 先确保已安装：
composer require --dev squizlabs/php_codesniffer - 在
composer.json的scripts段加："cs": "phpcs"，并配套放phpcs.xml配置文件（否则默认无规则） - 配置文件里可微调规则，比如限制行宽：
<rule ref="Generic.Files.LineLength"><properties><property name="lineLimit" value="120"></property></properties></rule> - 修复脚本也建议加上：
"cs-fix": "phpcbf"，但 CI 中禁用自动提交，避免它误修非目标文件
最易被忽略的是：所有这些校验都只覆盖自己负责的边界。validate 不管 vendor/ 内容，verify-checksums 不管代码逻辑，phpcs 不管依赖声明。生产部署前，autoload.php 这类关键引导文件完全游离在校验体系外——它既不在 composer.lock 哈希中，也不受任何静态分析约束，被注入恶意代码时 Composer 无法感知。
