repositories字段必须写在composer.json根级，type仅支持vcs、composer等合法类型，url须为可克隆地址且name大小写严格匹配require中的包名。
必须在项目根目录的 composer.json 的 repositories 字段里显式声明，否则 composer require 一定失败，报 Could not find package。
repositories 字段怎么写？
这是最关键的一步，不是可选项。Composer 不会自动发现你内网或私有 Git 上的包，必须手动告诉它地址和类型。
-
type必须是"vcs"（直连 Git）或"composer"（对接 Satis / Private Packagist），不能写成"git"、"package"或漏掉 -
url是 Git 仓库根路径（含composer.json的那个地址），不要加.git后缀；HTTPS 地址不带认证凭据，SSH 地址要确保本地ssh-agent已加载对应密钥 - 多个私有源就写成数组，顺序重要：Composer 按
repositories数组从左到右查找，命中即停 - 示例（GitHub 私有库）：
{ "repositories": [{ "type": "vcs", "url": "https://github.com/myorg/utils" }] }
require 里的包名为什么总对不上？
Composer 查包时，先匹配 repositories 里的地址，再严格比对 name 字段 —— 它和你 require 写的字符串必须完全一致，包括大小写、斜杠方向、vendor 名。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Git 仓库根目录下的
composer.json里必须有"name": "myorg/utils"，不能是"MyOrg/utils"或"myorg-utils" -
require里写"myorg/utils": "^1.0"，如果没打v1.0.0这类语义化 tag，就得写"dev-main"，且需配合"minimum-stability": "dev" - 调试方法：运行
composer show myorg/utils --all，看它实际识别出哪些版本；如果输出为空，说明 name 或 repositories 没对上
认证凭据放哪儿才生效？
凭据绝不能塞进 composer.json，也不能拼在 URL 里（如 https://token@...），必须走 auth.json，且路径和权限有硬性要求。
-
auth.json放在项目根目录（与composer.json同级）最安全；全局路径（如~/.composer/auth.json）易冲突，CI 环境推荐用COMPOSER_AUTH环境变量 - 文件权限必须是
600（Linux/macOS 下执行chmod 600 auth.json），否则 Composer 静默忽略，报Authentication failed却不提示原因 - HTTPS 类型私有库用
http-basic，key 填域名（如"gitlab.internal"），不是完整 URL；GitHub 私有库优先用github-oauth+ PAT（scope 至少含read:packages）
为什么打了 tag 还装不到？
Composer 对 VCS 包的版本解析只认 Git tag 和分支名，完全忽略 composer.json 里的 version 字段。打错 tag 格式或缓存未清，就会找不到。
- tag 必须符合语义化格式：推荐
v1.0.0或1.0.0；v1.0、1.0、feature/login都不被识别为 stable 版本 - 改了 tag 对应的 commit 并强制推送后，Git 服务器可能缓存旧内容，本地必须执行
composer clear-cache再composer update - 如果用 Satis，tag 打了但没运行
php bin/satis build，packages.json就不会更新，客户端永远查不到新版本
