应通过项目级 composer.json 的 repositories 数组硬编码私有源并提交 Git，优先声明私有 composer 类型源并显式禁用 packagist.org，默认源关闭需确保有可用替代源。
团队共享的 Composer 仓库源不能靠每个成员手动改 composer.json 或全局 config.json，那样极易不一致、难同步、易覆盖。真正可行的方式是通过项目级配置 + 可版本控制的 composer.json 配置项实现统一源管理。
如何用 repositories 在项目中硬编码私有源
这是最直接、最可控的做法：把私有包源声明在项目根目录的 composer.json 中，提交进 Git。Composer 会优先使用这里的 repositories，且所有成员执行 composer install 时自动生效。
常见错误现象：只在自己机器上运行 composer config repositories.xxx ...，结果别人 composer install 报 Could not find package xxx —— 因为这个命令只改本地 ~/.composer/config.json，不进版本库。
-
repositories必须是数组，类型支持composer（官方或私有 Packagist）、vcs（Git 仓库）、package（单包定义） - 若使用私有 Packagist（如 Satis、Private Packagist、JFrog Artifactory），类型设为
composer，URL 填其packages.json地址（例如https://pkgs.example.com/packages.json） - 多个源按顺序匹配，建议把私有源放前面，避免公共包被错误路由到内网源
- 示例片段：
{
"repositories": [
{
"type": "composer",
"url": "https://pkgs.internal.company.com"
},
{
"type": "packagist.org",
"url": "https://packagist.org"
}
],
"minimum-stability": "stable",
"prefer-stable": true
}
为什么不要用 composer config --global 配置团队源
全局配置写入 ~/.composer/config.json，它对所有项目生效，但无法纳入版本控制，也无法差异化适配不同项目（比如 A 项目用内部源，B 项目必须走公网）。一旦某人误操作清空或覆盖，整个本地环境就失效。
更隐蔽的问题是：CI/CD 流水线（如 GitHub Actions、GitLab CI）默认没有全局配置，如果构建脚本依赖全局源设置，就会失败；而项目级 repositories 是自带的，无需额外 setup。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 环境通常重装 Composer，
--global配置不存在 - 不同分支可能需不同源策略（如
dev分支用 snapshot 源，main用 release 源），全局配置做不到动态切换 - 新人 clone 项目后，
composer install直接失败，还得查 Wiki 手动配一遍 —— 违背“开箱即用”原则
如何安全地覆盖 packagist.org 的默认行为
Composer 默认始终启用 packagist.org，即使你写了私有源，它仍会在找不到包时回退查询公网。这在内网环境中可能引发超时、泄露依赖信息，甚至因防火墙策略失败。
正确做法是显式禁用默认源，并仅保留明确声明的源：
- 在
repositories数组中加入{"type": "packagist.org", "url": false}，这是 Composer 1.7+ 支持的语法，表示“彻底关闭默认源” - 确保至少有一个可用的替代源（比如你的私有 Packagist），否则所有非本地包都会安装失败
- 注意：不是所有私有源都完整镜像了 packagist.org，缺失的包要单独用
package类型声明，或提前同步
示例：
"repositories": [
{
"type": "composer",
"url": "https://pkgs.internal.company.com"
},
{
"type": "packagist.org",
"url": false
}
]
真正麻烦的不是加一行配置，而是让所有人理解“源是项目契约的一部分”——它和 PHP 版本要求、扩展依赖一样，该进 Git，该写进 README，该在 CI 脚本里被验证。漏掉任意一环，共享就变成幻觉。
