composer validate --strict是真正起效的校验方式，它启用完整Schema校验，检查字段值合法性（如name含空格、version格式错误、拼写错误等），而默认模式仅做基础JSON解析和必填字段存在性检查，故常显示“OK”却实际出错。
Composer validate 命令本身不校验业务逻辑，只检查 composer.json 的 JSON 语法、字段合法性与基本约束（比如 name 格式、version 是否合法），但它确实能拦住 80% 以上的低级配置错误——前提是运行时带上 --strict。
为什么默认 composer validate 总是显示 “OK” 却仍出问题？
默认行为只做基础 JSON 解析 + 必填字段存在性检查，不验证字段值是否符合 Composer 规范。例如：
-
"name": "my/package"合法；但"name": "my package"（含空格）在严格模式下才报错 -
"version": "1.0"被接受；而"version": "v1.0"在--strict下会提示 “invalid version constraint” - 拼错字段如
"requies"（应为require）在非严格模式下静默忽略
如何让 composer validate 真正起作用？
必须显式加 --strict 参数，它会启用完整 Schema 校验（基于 Composer 内置的 res/composer-schema.json）：
composer validate --strict
建议在 CI 流程或 pre-commit 钩子中固定使用该命令。若项目需兼容旧版 Composer（--strict 在 2.0+ 才成为稳定选项；低于此版本可用 composer validate --no-check-all 辅助定位，但效果有限。
常见报错及对应修复点
遇到以下错误时，别急着改代码，先确认是不是 composer.json 的硬性规则被违反：
-
Invalid value for 'name': 'vendor/name' must be lowercase and contain only letters, digits, underscores, hyphens and dots→ 检查大小写、特殊字符（如中文、空格、@） -
The property 'autoload' is required→ 即使不自动加载，也得写"autoload": {"psr-4": {}}或至少"autoload": {} -
Invalid version constraint 'dev-master'（在require中）→dev-前缀只允许出现在repositories或config的特定上下文，生产依赖请用^1.0或具体 commit hash
Schema 校验不会告诉你“这个包是否真能装上”，也不会检查网络可达性或权限问题——那些是 composer install 阶段的事。真正容易被忽略的是：CI 环境里如果用了缓存的 composer.lock，validate 可能绕过对 composer.json 的重新解析，导致误判。每次校验前，确保你操作的是当前工作区真实的、未被覆盖的配置文件。
