composer validate 是基础语法和结构检查工具，通过不等于能发布成功；报错“line 12 at column 5”即精确位置，需查末尾逗号、单引号/中文标点、隐藏字符；绕过 Composer 用 php -r "json_decode(...)" 定位更准；加 --strict 才启用字段合法性等完整校验。
它不是安全防线，而是基础语法和结构检查工具——通过了不代表能发布成功，失败了也不代表不能用。
composer validate 报 JSON parse error 怎么快速定位
错误信息里写的 line 12 at column 5 就是精确位置，不是示意。编辑器跳转过去，盯三类高频问题：
- 末尾多逗号：比如
"require": {"monolog/monolog": "^3.0",}最后那个逗号必须删 - 单引号或中文标点：
'name': 'myorg/myapp'❌，必须是"name": "myorg/myapp" - 隐藏字符：从网页复制内容可能带零宽空格（U+200B）或 BOM 头（
ef bb bf），可用cat -A composer.json | head -n 15查
绕过 Composer 直接测 JSON 合法性更准：php -r "json_decode(file_get_contents('composer.json')) or die('JSON error: '.json_last_error_msg());"
为什么加 --strict 才算真正有用
默认模式下，很多低级错误会被忽略——autoloader 拼成 autload、type 写成 libary、license 填 MIT License（非 SPDX 标准），全都不报错。只有加 --strict 才会中断：
Property autoloader is not definedRequired key "description" is missingValue "dev-master" is not an allowed value
CI/CD 中必须固定用 composer validate --strict --no-check-publish：前者把警告变错误，后者跳过 Packagist 发布检查（避免网络超时中断流程）
validate 通过了，但 packagist.org 提交失败的常见原因
composer validate 完全不联网，也不查仓库权限或元数据规则。提交失败常因静默拦截：
-
name字段已被占用，但你用的是 fork 分支，Packagist 不接受重复名 -
source仓库设为私有或 GitHub 的 private repo，Packagist 无法读取 -
dist的 zip URL 返回 403，比如 GitHub Releases 设置了下载限制 -
autoload路径声明与实际文件结构不一致，导致 Packagist 解析 classmap 时失败（validate阶段不校验路径是否存在）
真正暴露这类问题的命令是 composer install --dry-run，它会模拟完整安装流程，包括远程元数据获取和 autoload 路径验证
autoload 配置错导致本地 OK、发布后 Class not found
composer validate 不加载类、不扫描文件、不检查路径是否存在。所以即使 autoload 写错，只要 JSON 和 schema 合规，它就安静放行。
- PSR-4 映射末尾漏掉反斜杠：
"My\Package": "src"❌，必须是"My\Package\": "src/" -
files类型引用的 PHP 文件含语法错误，validate完全不检查 - 测试前没删掉
vendor/和composer.lock，本地缓存掩盖了映射失效问题
实操建议：运行 composer dump-autoload -o 后，手动执行 php -r "require 'vendor/autoload.php'; new VendorPackageSomeClass();" 测试实例化，再模拟全新安装场景
最常被忽略的一点：validate 只管“写得像不像人话”，不管“说的包存不存在”——它连 "php": ">=8.3" 和当前环境是否匹配都不看，那块得靠 composer check-platform-reqs。
