项目级镜像配置必须在composer.json的repositories数组中严格按顺序声明：首项{"packagist.org": false}禁用官方源，次项为镜像源；且需清理vendor和composer.lock后执行composer install。
composer.json里repositories字段怎么写才被识别
Composer只在composer.json顶层的repositories数组中查找自定义源，写错位置或格式就完全忽略——它不会报错，也不会提示你哪里不对。
-
repositories必须是**数组**（[]），不是对象（{}）；写成"repositories": {}会导致后续所有配置失效 - 每项必须显式声明
"type": "vcs"，不能省略，也不能写成"git"或"package" -
url值必须是可直接git clone的地址：HTTPS 格式要带.git后缀（如https://gitlab.example.com/acme/utils.git），SSH 格式要含@和:（如git@gitlab.example.com:acme/utils.git） - 如果同时用私有源+镜像，
repositories数组里要先放镜像项，再放私有项；顺序不影响功能，但便于维护
auth.json放哪、权限和字段怎么设才生效
Composer读取认证凭据只认一个路径、一种结构、一套权限，其他任何地方写的auth.json都会被静默跳过。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS 路径必须是
~/.composer/auth.json（注意是当前执行用户的家目录，不是项目根目录） - Windows 路径必须是
%APPDATA%\Composer\auth.json - 文件权限必须是
600：chmod 600 ~/.composer/auth.json，否则 Composer 直接忽略 - 认证字段只能用
"http-basic"，结构为：{"http-basic": {"gitlab.example.com": {"username": "oauth2", "password": "glpat-xxx"}}}；域名gitlab.example.com必须和repositories.url中的 host 完全一致（不含端口、协议、路径）
require包名匹配失败的三个硬性条件
“Could not find package”几乎从不因为网络或镜像问题，而是因为 Composer 对包名校验极其严格——差一个字符、大小写不对、缺 vendor 段，就彻底失败。
- 必须和私有仓库根目录下
composer.json里的name字段**逐字完全一致**（如"acme/utils"，不能是"Acme/utils"或"acme-utils"） - 版本约束必须加
dev-前缀：默认分支是main，就得写"dev-main"；写"main"或"*"会被当成模糊匹配，去 packagist.org 查，查不到就报错 - 如果私有库没打任何 tag，唯一可用版本就是
dev-main（或dev-master，取决于 Git 默认分支名）
为什么配了私有源还去连packagist.org
这是最隐蔽也最常被忽略的问题：Composer 默认会把 packagist.org 当作兜底源，哪怕你写了私有 URL，它也会先去官方源查一遍——查不到才 fallback。结果就是私有包永远找不到。
- 必须在
composer.json顶层（和repositories同级）加这一行："packagist.org": false - 这个字段不能写在
repositories内部，也不能写成"packagist": false或"packagist.com": false - 禁用后，基础扩展依赖（如
ext-json、php）仍能正常校验，无需额外处理 - 如果用了 Artifactory 或 Satis 等虚拟源，也要确保其后端至少包含一个
type: composer的仓库，否则"packagist.org": false一加，整个安装就卡住
