composer.json 键顺序不统一会导致Git diff混乱、CI误报变更、合并冲突；用composer-normalize可规范根级键及require等嵌套字段顺序，但不重排repositories、自定义字段、config和extra内容。
为什么 composer.json 键顺序不统一会带来实际问题
不同开发者保存 composer.json 时，键的排列顺序五花八门：name 可能在最后，require 插在中间，autoload 又跳到开头。Git 提交 diff 里全是键位置变动，根本看不出哪行是真修改；CI 中因格式差异触发无意义的变更检测；多人协作时还容易因手动调整顺序引发合并冲突。
用 composer-normalize 统一排序（推荐方案）
社区工具 composer-normalize 是目前最轻量、最可靠的选择，它不改逻辑，只规范结构。安装后运行一次就能让所有键按预设规则重排。
- 安装：在项目根目录执行
composer require --dev ergebnis/composer-normalize - 规范化：运行
composer normalize，它会自动重排composer.json的根级键和嵌套字段（如require内部包名也按字母序排） - 验证：加
--dry-run参数先看效果，不写入文件 ——composer normalize --dry-run - 注意：该工具默认不处理
scripts字段的执行顺序，但会把脚本名本身按字母排序
如何让团队每次提交都自动合规
靠人手动跑命令不可靠，必须嵌入工作流。
- 加 Git 预提交钩子：用
composer-normalize自带的钩子功能，执行composer normalize --git-hooks，它会在.git/hooks/pre-commit写入校验逻辑 - CI 中强制检查：在 GitHub Actions 或 GitLab CI 脚本里加一步
composer normalize --dry-run，失败即中断构建 - 别把
composer.json排序规则写进 IDE 设置：不同人 IDE 配置不一致，且 IDE 不会重排嵌套结构（比如require-dev里的包顺序），只有composer-normalize能覆盖全量
哪些字段会被重排？哪些不会？
composer-normalize 默认重排全部标准字段，但有明确边界：
- 重排的：根级键（
name、type、description、require、autoload等），以及require/require-dev内部的包名 - 不重排的：自定义字段（如你加的
x-custom-config）、config下的任意子项、extra全体内容 —— 它们保持原顺序，避免破坏第三方工具读取逻辑 - 特别注意：
repositories数组不会被重排顺序，因为顺序可能影响源优先级（第一项{"packagist.org": false}必须在前）
真正容易被忽略的是 repositories 字段：它必须是数组且首项为禁用官方源的开关，这个顺序不能靠工具自动保证，得靠人工确认或 CI 脚本校验。
