composer validate仅校验composer.json语法与字段结构，不验证依赖可行性；报错如“line 23 at column 17”为精确位置，需查末尾逗号、单引号、全角符号、bom头等；加--strict才启用语义校验，ci中须组合--strict --no-check-publish --lock并辅以install --dry-run。
composer validate 不是“能不能装上”的判断依据，它只告诉你 composer.json 写得像不像人话——语法对不对、字段拼没拼错、结构合不合规范。
报 JSON parse error 怎么快速定位到具体字符
错误信息里写的 line 23 at column 17 就是真实出错点，不是示意。打开编辑器直接跳转过去，别重写整个文件。
- 末尾多出的逗号（尤其在
"require"、"autoload"对象最后一项后） - 单引号代替双引号（
'name': 'myorg/myapp'❌，必须是"name": "myorg/myapp"） - 从网页复制来的全角标点（中文
，或：）、零宽空格（U+200B） -
//或/* */注释（JSON 标准不支持） - 文件编码是 UTF-8 with BOM（Windows 记事本易中招），右下角确认是纯 UTF-8
更快验证纯 JSON 合法性：php -r "$j = file_get_contents('composer.json'); $d = json_decode($j); if (!$d) { echo json_last_error_msg().\"\n\"; }"，报错比 composer validate 更直白。
为什么默认模式下很多错误被放过去了
composer validate 默认只把硬性语法错误当失败，其余全当警告——CI 里不加 --strict 就等于没校验。
-
"autoloader": {}→ 拼错字段名，应为"autoload"，默认不拦，--strict直接失败 -
"type": "libary"→ 拼错且值非法，--strict才报错 -
"license": "MIT License"→ 非 SPDX 标准值，--strict才变错误 -
"minimum-stability": "dev-master"→ 已弃用写法，--strict才拒绝
CI 脚本必须用：composer validate --strict --no-check-publish。--no-check-publish 跳过 Packagist 发布检查，防网络超时中断流程。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
validate 通过了，install 却失败？这是设计使然
composer validate 完全不联网、不查 Packagist、不运行依赖求解器。它只读字符串，不管逻辑。
-
"monolog/monolog": "999.0.0"→validate说 OK，install报Could not find package - 私有包
"myorg/mylib"没配repositories→validate沉默，install才炸 -
"php": ">= 8.1"带空格会通过validate，但install报Invalid version constraint
真正暴露依赖问题的命令是：composer install --dry-run。它模拟完整安装流程，校验包存在性、版本可解析性、锁文件一致性，且不写 vendor、不改缓存。
CI 中怎么组合才真正可靠
单跑 composer validate 是高风险操作。生产级校验底线是分层验证：
-
composer validate --strict --no-check-publish：语法 + schema + 必填项全检，跳过网络依赖 -
composer validate --lock：显式校验composer.lock是否由当前composer.json生成（防止手动改json后忘了update） -
composer install --dry-run --no-interaction：走完依赖求解全流程，但不下载、不写盘
最容易被忽略的一点：validate 和 --dry-run 都不校验 vendor 目录里文件是否被篡改或缺失——它们只管配置和依赖逻辑。
