Composer validate –strict模式 严格校验配置文件格式【规范】

composer validate –strict 会校验字段类型、必填性、值范围、结构嵌套等，如 name 必须为 vendor/name 格式、autoload psr-4 映射值须为有效目录路径、php 版本建议用语义化约束；它启用完整 jsON Schema 校验与额外语义检查，确保配置符合 Packagist 发布标准，提升 CI 可靠性与协作一致性。

composer validate –strict 会校验哪些配置项

composer validate --strict 不只是检查 composer.json 是否合法 JSON，它还会强制验证字段类型、必填性、值范围和结构嵌套。比如：name 必须是 vendor/name 格式（含斜杠）、version 不能出现在根级（除非是仓库内锁版本）、autoload 中的 psr-4 映射值必须是目录路径（末尾带 / 或为 ""），且键必须以命名空间结尾加反斜杠。

常见被拦住的写法包括：

• "name": "myapp" → 缺少 vendor 部分，应为 "myapp/myapp"
• "autoload": {"psr-4": {"App\": "src/App"}} → "src/App" 不是有效目录路径（缺尾部 / 或 ""），应改为 "src/App/" 或 "src/"
• "require": {"php": ">=7.4"} → 在严格模式下，PHP 版本约束建议用 ^7.4 || ^8.0 等语义化写法，纯比较符容易触发警告（虽不报错，但 --strict 下部分警告升为错误）

为什么 CI 中推荐加 –strict 而不是只跑默认 validate

默认 composer validate 只做基础 JSON 和 schema 合理性检查，很多格式隐患（如 autoload 命名空间漏反斜杠、type 字段拼错成 tyep）会被放过。而 CI 是自动化流程，一旦这类问题合入主干，后续 dump-autoload 可能静默失败，或导致依赖安装时无法正确加载类。

--strict 实际上启用了 Composer 内置的完整 JSON Schema 校验（对应 https://getcomposer.org/schema.json 的 latest 版本），并开启额外语义检查。它和 Packagist 提交包时执行的校验逻辑基本一致——也就是说，本地过不了 --strict，大概率无法成功发布到 Packagist。

validate –strict 失败但本地能正常 install/dump-autoload 怎么办

这说明你的配置存在“运行时容忍但规范不接受”的情况。Composer 运行时为了兼容性会宽松处理（比如自动补 /、忽略多余空格），但 --strict 是面向协作与发布的守门员。

典型场景和修复方式：

• "autoload": {"classmap": ["src"]} → 如果 src 是空目录或不含 PHP 文件，--strict 会警告“classmap path does not exist or is not readable”；解决：删掉该条目，或确保路径真实存在且含 PHP 文件
• "scripts": {"post-install-cmd": "MyScript::run"} → 若 MyScript 类未在 autoload 中声明，或方法不可访问，--strict 不直接报错，但会提示 “script name does not match any known script type”；应改用标准钩子名（如 post-autoload-dump）或确认类已正确注册
• 使用了废弃字段，如 support.email 写成 support.emails → 字段名错位，--strict 直接拒绝

如何让 validate –strict 成为开发习惯

最轻量的方式是加到 composer.json 的 scripts 里：

"scripts": {   "validate": "composer validate --strict" }

然后每次提交前手动跑 composer run validate；更进一步可接入 pre-commit hook（如通过 composer-normalize + husky 组合），或在 .github/workflows/composer.yml 中固定加入：

- name: Validate composer.json   run: composer validate --strict

注意：不同 Composer 版本对 --strict 的校验粒度略有差异（如 2.2+ 加强了 bin 字段路径检查），建议团队统一 Composer CLI 版本，并在 composer.json 的 config.platform.composer 中锁定最低允许版本。

真正容易被忽略的是：严格模式不校验 vendor 目录或 lock 文件，但它要求 composer.json 本身具备可重入性——也就是说，哪怕你删掉 vendor 和 composer.lock，仅靠这个 JSON 也应能无歧义地重建整个依赖图。任何靠“我本地有缓存所以能过”的侥幸，都会在 CI 或新成员 clone 后第一秒暴露。