答案是阿里云镜像不托管私有包，仅缓存packagist.org公开包；Composer会绕过镜像直连私有源，导致“Could not find package”或元数据错乱。
不能直接用阿里云镜像拉取自研包——它只缓存 packagist.org 公开包，对 internal/auth-sdk 这类私有包完全无感知。 配错会导致 Could not find package 或元数据错乱，不是网速问题，是源声明逻辑错了。
为什么 composer config -g repo.packagist https://mirrors.aliyun.com/composer/ 对私有包无效
阿里云、腾讯云等镜像只托管 packages.json 和 provider 文件，不托管 ZIP 包，更不索引你公司 Git 仓库里的 internal/auth-sdk。Composer 发现你要装的包不在镜像里，就会跳过镜像、直连你 composer.json 里写的私有源地址（比如 https://repo.internal/ 或 git@corp.gitlab/internal/auth-sdk），此时镜像配置形同虚设。
- 执行
composer show internal/auth-sdk --verbose，看dist.url是不是指向 GitHub 或你内网 Git 地址——如果是，说明根本没走镜像 - 错误现象：卡在
Cloning、报Could not find package、或拉到旧 tag - 风险点：
"packagist.org": false会切断 fallback，但不会让私有源变快；若误把私有源 URL 写成阿里云地址，必然 404
私有包必须单独声明 repositories，且 type 不能是 composer
私有包提速靠的是「减少网络跳转 + 避免重复认证」，不是走 CDN。关键动作是显式声明源类型，并把认证前置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Git 类型私有包，优先用
"type": "vcs"，例如：{"type": "vcs", "url": "https://gitlab.internal/internal/auth-sdk"} - HTTP 类型私有源（如 Satis），必须用
"type": "composer"，URL 必须以/结尾："url": "https://repo.internal/" - 凭据绝不能硬编码进
composer.json，用composer config http-basic.repo.internal username password存进auth.json -
auth.json必须加进.gitignore；如果 URL 是 IP（如https://192.168.1.100），http-basic映射会失效
混合源场景下如何避免 public 包被私有源污染
项目同时依赖 monolog/monolog 和 internal/auth-sdk 时，顺序和开关控制不当，会导致解析失败。
- 私有源必须放在
repositories数组第一位，Composer 按顺序查找，不会合并同名包 - 别写
"packagist.org": false—— 它只禁用默认源，不阻止 Composer 尝试其他composer类型源 - 真要隔离 public 包，用顶层
"packagist": false（注意没.org） - 如果用了 Satis，确保其
satis.json中require-all: true没开启——它会同步全部公开包，首构建超 40GB，还暴露 dev 分支
验证私有源是否真正生效的三步法
别等 composer install 卡住才排查。真实请求路径必须亲眼确认。
- 运行
composer config --list | grep repositories，确认输出含你配的私有源 URL - 执行
composer show internal/auth-sdk -vvv 2>&1 | grep "Downloading\|Resolving"，看实际请求域名是不是repo.internal或 Git 地址 - 手动 curl 测试 ZIP 可达性：
curl -I https://repo.internal/dist/internal/auth-sdk/1.2.0/xxx.zip，检查 HTTP 200 和Content-Length - 容易忽略的坑：
vendor/和composer.lock必须清掉再重装，否则旧 lock 仍指向原始 dist.url
最常被绕过的环节是：Satis 输出目录没被 Web 服务正确暴露，或 Nginx 缺少 types { application/json json; } 导致返回 text/plain，Composer 静默拒收。这不是配置问题，是部署链路断在了最后一步。
