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 后第一秒暴露。
