preferred-install 控制包默认安装方式但不强制执行，值为"dist"/"source"/"auto"，配置写入composer.json的config.preferred-install并影响composer.lock，命令行参数优先级高于它，lock文件中已存方式优先级最高。
它不决定“装什么”，只影响“怎么装”——但一旦配错，CI 构建会卡在 git clone，Docker 镜像里会多出一堆没用的 .git 目录。
preferred-install 是配置项，不是命令行开关
它写在 composer.json 的 config.preferred-install 里，控制包的默认获取方式。和 --prefer-dist 这类命令行参数不同，它不临时生效，而是被记录进 composer.lock，后续 composer install 会严格按这个策略还原安装行为。
常见误操作是：本地加了 "prefer-source": true 跑通开发，却忘了删掉就提交到 Git —— 结果 CI 拿着这个 lock 文件去跑，发现机器没装 git，直接报错 Failed to execute git clone。
-
"preferred-install": {"*": "dist"}→ 所有包默认走压缩包（推荐生产环境） -
"preferred-install": {"myorg/private-sdk": "source", "*": "dist"}→ 只有私有 SDK 必须源码，其余照常 dist - 值只能是
"dist"、"source"或"auto"（等同于不设，交由 Composer 自动判断）
为什么设置了 preferred-install，某些包还是走 source？
因为 preferred-install 是“偏好”，不是强制。Composer 会检查每个包是否实际支持该方式：如果包的 composer.json 根本没声明 source 字段（比如纯 ZIP 发布的私有库），哪怕你写了 "*": "source"，它也 fallback 回 dist；反之，若包禁用了 dist（例如只提供 "type": "git" 且没配 dist），"*": "dist" 也会失效。
验证方法很简单：composer show vendor/package，看输出里有没有 source: git@... 或 dist: https://...zip 行。没有对应字段，配置就不起作用。
- 开发分支约束（如
"dev-main"）通常不发 dist，自动退到 source - 本地
path类型仓库天生就是 source，preferred-install对它无效 - lock 文件里已存的安装方式优先级高于
preferred-install，除非加--force-reinstall
preferred-install 和 --prefer-dist / --prefer-source 的关系
三者可以共存，但优先级不同：composer install --prefer-source > preferred-install 配置 > 默认行为。也就是说，命令行参数能覆盖配置，但配置不会覆盖 lock 文件里已固化的方式。
最稳的实践是：CI 环境一律用 composer install --prefer-dist --no-dev 显式指定，不依赖配置；本地开发若需调试某几个包，用 composer require vendor/name:dev-main --prefer-source 单点启用，避免全局污染 composer.json。
-
--prefer-dist和--prefer-source是一次性动作，不改 lock -
preferred-install改了要composer update才会写入 lock - Docker 构建中混用二者容易导致缓存失效：前一次用 source 装的 vendor 有
.git，后一次用 dist 就得全量重下
真正容易被忽略的是 lock 文件的“惯性”——它记下的不只是版本号，还有当时用的安装方式。哪怕你把 preferred-install 从 source 改成 dist，只要不删 lock 或加 --force-reinstall，composer install 仍会按老方式还原。这点在跨环境部署时特别致命。
