私有包不走镜像源同步，必须将私有源置于repositories数组首位且URL末尾带/；{"packagist": true}需单独作为最后一项兜底；全局config -g repo.packagist对私有源无效。
私有包根本不会走镜像源同步，所谓“遗漏”是配置逻辑错位导致的假象——它压根不参与镜像元数据拉取流程。
私有源必须放在 repositories 数组首位
Composer 查找包时严格按 repositories 数组顺序遍历，一旦中间某项（比如阿里云镜像）返回 “package not found”，就会直接报错并终止，根本不会继续往后检查你的私有源。
- 错误写法：
"repositories": [{"type":"composer","url":"https://mirrors.aliyun.com/composer/"},{"type":"composer","url":"https://pkgs.internal/artifactory/api/composer/internal/"}]—— 私有源被跳过 - 正确写法：私有源必须是数组第一项，且
url末尾必须带/，否则拼出的packages.json路径 404 - 不能用对象写法：
"repositories": {"internal": {...}}—— Composer 只读第一个 key，其余静默丢弃
packagist.org 元数据兜底项必须单独存在
{"packagist": true} 不是下载源，而是告诉 Composer：“如果前面所有 repositories 都没命中，最后去 packagist.org 查一次元数据”。它不参与 ZIP 下载，只解决新包漏索引问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须作为数组最后一项，且独立成项，不能合并进私有源对象里
- 不能写成
{"packagist.org": false}却不加{"packagist": true}—— 这会导致所有非私有包都查不到 - 写了
"packagist.org": false但没显式加{"packagist": true}，等同于关闭全部公共源
auth.json 必须在项目根目录或通过环境变量注入
私有源认证失败时，401 Unauthorized 或 could not find package 看似是“找不到”，实则是认证断在第一步，连元数据请求都没发出去。
-
auth.json必须和composer.json同级；~/.composer/auth.json在 CI 容器、宝塔、GitHub Actions 中通常不可见 - 推荐用
COMPOSER_AUTH环境变量注入 JSON 字符串，避免文件挂载权限问题 - Token 权限必须含
read:packages（GitLab）或read_package_registry（GitHub），仅api权限不够
全局 config -g repo.packagist 对私有包完全无效
执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 只改 packagist.org 的代理地址，对任何 type: "composer" 的私有源都不起作用。
- 只要项目
composer.json里有repositories字段（哪怕只是[]），全局配置就被彻底屏蔽 - CI 构建机用
runner用户运行命令，但-g写到了root的~/.composer/config.json，实际没生效 - 本地测试用了全局镜像，一推到 GitLab CI 就报 401 —— 因为容器里既没
auth.json，也没COMPOSER_AUTH
最易被忽略的一点：私有包的元数据请求路径是 https://pkgs.internal/.../packages.json，而镜像源的 packages.json 永远不会包含私有包信息。别指望“等镜像同步”，它本来就不该同步。
