preferred-install 是 composer 控制新包安装方式的配置项，可设为 source、dist 或 auto，仅影响首次安装；需在团队调试、ci 构建或私有包部署等场景下按需调整。
preferred-install 是什么，什么时候需要改它
preferred-install 是 Composer 的全局或项目级配置项，控制新包默认以哪种方式安装：源码（source）、dist（压缩包，dist）还是自动判断（auto）。它不改变已安装包的行为，只影响 composer require 或 composer install 时的首次拉取策略。
常见触发场景包括：
- 团队开发中需要统一调试能力（强制
source，方便断点进 vendor） - CI 环境追求安装速度与磁盘节省（强制
dist） - 私有包托管在 GitLab/GitHub，但希望跳过 clone（避免 token 权限问题），改用 dist
怎么设置 preferred-install：三种作用域的区别
配置生效范围优先级：项目 composer.json > 当前用户 auth.json > 全局 config（composer config -g）。生产环境建议锁死在项目级，避免因开发者本地配置污染构建结果。
设置方式如下：
- 项目级（推荐）：
composer config preferred-install "dist"
- 全局（慎用）：
composer config -g preferred-install "source"
- 手动写入
composer.json："config": { "preferred-install": "dist" }
注意：preferred-install 不支持 per-package 细粒度控制；若只想对某个包用 source，得配合 composer config --unset repositories.* + 手动 git clone + composer install --no-update，再软链。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
dist 和 source 安装的实际差异在哪
核心区别不在“能不能用”，而在“怎么来”和“后续可否改”：
-
dist：下载 zip/tar 包，解压后无 .git 目录，无法git pull，但安装快、体积小、适合部署 -
source：执行git clone，保留完整仓库信息，可切分支、查 commit、打 patch，但依赖 git 可用性与网络权限
容易踩的坑：
- 设为
source后，私有 GitLab 包若没配好 SSH key 或 deploy token，composer install会卡在 “Cloning into…” 并静默失败 - 某些镜像源（如阿里云）不代理 source 安装，仍会直连 GitHub，导致超时
-
preferred-install对已存在的 vendor 包无效——删掉vendor/再install才生效
为什么 auto 不是万能解，反而常被忽略
auto 是默认值，逻辑是：有 dist URL 就用 dist，否则 fallback 到 source。听起来合理，但实际受 packagist.org 元数据影响很大：
- 包作者没填
dist字段（老包或自建 repo 常见）→ 强制走 source - GitHub Rate Limit 触发时，
auto下的 source 安装可能突然失败，而 dist 安装不受影响 -
composer update --with-dependencies时，子依赖若 metadata 缺失 dist，整个链路可能降级为 source
所以，明确场景下主动设为 dist 或 source，比依赖 auto 更可控。尤其上线前的构建脚本里，别留这个隐式变量。
真正麻烦的不是设哪个值，而是设完之后没验证 vendor 里到底有没有 .git 目录，或者没确认私有包是否真的走 dist 下载了。
