composer format是composer 2.5.0+原生命令，仅重排缩进、空行、引号与逗号，不改变字段顺序、不删注释、不重排require/scripts，比composer-normalize和jq更安全可靠。
直接用 composer format，别碰 composer-normalize —— 除非你明确需要排序 key 或强制尾逗号，否则它只会给协作添乱。
composer format 是什么，为什么它比 normalize 更安全
composer format 是 Composer 2.5.0+ 原生命令，只重排缩进、空行、引号与逗号位置，不改变字段顺序、不删注释、不重排 require 或 scripts 的先后关系。而 composer-normalize 默认会 sort-keys: true，把 autoload 往前挪、scripts 往后塞，破坏人眼可读性；它还会把多行 shell 命令压成一行，让 CI 脚本难以 review。
常见错误现象：composer-normalize 把你手写的 "post-install-cmd": ["php bin/init.php", "chmod +x bin/deploy.sh"] 改成单行字符串，或把 "require-dev" 重排到 "require" 前面，导致某些依赖管理插件（如 composer-merge-plugin）解析失败。
- 执行前先确认版本：
composer --version≥ 2.5.0，否则先composer self-update - 预览改动不写入：
composer format --dry-run - 格式化指定路径：
composer format ./packages/foo/composer.json - CI 中校验是否合规：
composer format --dry-run && echo "OK" || (echo "FAIL: composer.json not formatted"; exit 1)
composer-normalize 的配置项怎么改才不至于翻车
如果你非要用 composer-normalize（比如团队已接入且无法立刻迁移），唯一值得动的配置是 skip-sorting。其他字段如 indent 或 trailing-comma 看似无害，实则可能和 IDE 设置冲突，造成 git diff 持续爆炸。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
必须设为 ["scripts", "require-dev"]，原因很实际：scripts 顺序影响执行链（比如 pre-install-cmd 必须在 post-install-cmd 前），require-dev 里包的安装顺序可能影响 conflict 解析结果。
-
配置文件名必须是
composer-normalize.json，拼错成normalize.json就静默失效 - 改完配置后必须重新运行
composer normalize，它不会自动监听文件变化 - Windows 下注意路径分隔符：配置里的
"src\"是错的，应统一用正斜杠"src/" - 不要开启
sort-keys: true同时又设skip-sorting: ["scripts"]——这会让其他字段（如autoload和config）被无意义重排，徒增 diff 噪声
为什么 jq / python -m json.tool 不能替代 composer format
它们输出的是「合法 JSON」，不是「可用的 composer.json」。jq . composer.json > tmp && mv tmp composer.json 表面看没报错，实际会干三件事：强制双引号（把 "^8.1" 变成 "^8.1"，看着一样但换行/空格变了）、删所有注释（哪怕只是 // TODO）、按字典序重排 key（name 跑最前，autoload 被挤到中间）。这些改动对 PHP 解析无影响，但对人和工具就是灾难。
-
python -m json.tool在 Windows 上默认用 cp1252 编码，遇到中文注释直接乱码，且不支持--dry-run -
jq不识别/* */注释（虽然 Composer 解析时也忽略，但开发者靠它标记临时禁用项） - CI 流程里用
jq格式化后再git diff --quiet判断是否变更，会因空格差异永远返回 false - 真正需要脚本化批量处理时，优先选
composer format --working-dir=xxx，它原生支持多项目遍历
validate --strict 和 format 不是二选一，而是必须串联
composer validate --strict 会拦住 "App": "src/"（缺双反斜杠）、"src/App"（路径末尾没 /）、"myapp"（name 缺 vendor 部分）这类问题；而 composer format 只管格式，不管语义。两者必须一起跑，顺序不能错：先 format 清理低级语法毛刺（比如漏逗号、混用引号），再 validate --strict 校验契约完整性。
- CI 中推荐写成两步：
composer format --dry-run && composer validate --strict -
validate --strict失败但本地install成功？说明配置存在“运行时容忍但规范不接受”的情况，比如src/目录当前为空，--strict 会警告“path does not exist”，但 Composer 运行时照常生成 autoload - 别在
composer.json里写"type": "project"后还手动加"autoload"——--strict会报 type 冲突，因为 project 类型默认不参与 Packagist 分发，autoload 应由上层约束
最容易被忽略的是：format 不修复语义错误，validate --strict 不修复格式错误。两者像两条平行校验线，缺一不可；而任何试图用通用 JSON 工具绕过它们的行为，最终都会在 CI 或上线时以更隐蔽的方式爆发。
