composer validate --no-check-all 仅校验 JSON 语法和官方 schema 合法性，跳过包名存在性、版本有效性、脚本可执行性等远程/上下文检查；CI 早期 lint 阶段可用，但部署前必须移除，且需确保 Composer ≥2.2。
为什么 composer validate --no-check-all 会跳过某些检查
composer validate 默认不仅校验 composer.json 的 JSON 结构和 schema 合法性，还会检查依赖包名是否存在、版本约束是否有效、脚本命令是否可执行等。加了 --no-check-all 后，它只保留最基础的两项：JSON 语法正确性 + 符合 Composer 官方 schema（比如 name 格式、type 取值范围）。其他远程或上下文敏感的检查全被绕过。
常见误用场景：CI 中用这个参数“加速验证”，结果上线后才发现 require 里写了不存在的包名，因为那个检查被跳过了。
-
--no-check-all不影响composer.json文件是否存在或是否可读 - 仍会报错：字段拼错（如
"reqire"）、version写成布尔值、autoload的psr-4映射值不是数组 - 不会报错：包名
vendor/missing-package实际不存在、dev-master分支已删除、脚本中调用的phpstan未安装
composer validate 和 composer install --dry-run 验证目标完全不同
有人以为加 --dry-run 是更“彻底”的快速验证，其实不是。composer install --dry-run 会解析全部依赖图、做版本冲突检测、检查平台配置（PHP 版本、扩展），甚至尝试匹配 platform 配置 —— 这比默认 validate 还重。它不校验 composer.json 本身是否合法，只是模拟安装流程。
- 想确认文件格式和基础字段：用
composer validate（或加--no-check-all加速） - 想确认能否成功安装（不含下载）：用
composer install --dry-run - 想同时检查两者？没有单命令，得串着跑：
composer validate && composer install --dry-run
CI 中该不该加 --no-check-all？看阶段
在 PR 触发的早期 lint 阶段，追求秒级反馈，--no-check-all 合理；但在部署前的 final check 阶段，必须去掉它，否则漏掉包名错误这类硬伤。
- GitHub Actions 示例（lint 阶段）：
run: composer validate --no-check-all --strict -
--strict要保留：它让警告（如缺少description）也变成错误，避免忽略低风险但规范性问题 - 注意
--no-check-all和--strict可共存，互不影响 - 若项目用了
composer.lock，验证时无需额外操作 ——validate本身不读 lock 文件
真正容易被忽略的兼容性细节
--no-check-all 在 Composer 2.2+ 才稳定支持；低于这个版本会静默忽略该参数，实际仍执行全量检查，但不报错也不提示。如果你的 CI 使用的是旧版 Composer（比如某些 Docker 基础镜像自带的 2.0.x），这个参数根本没生效。
- 查当前版本：
composer --version - 强制升级（推荐）：
curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer - 或者在
composer.json里声明最低要求："composer/composer": "^2.2"（仅限本地开发环境）
实际项目里，最常踩的坑不是参数用错，而是忘了团队成员本地装的 Composer 版本不一致，导致本地 validate 过了，CI 却失败 —— 或反过来。
