根本原因是命令写错三个硬性条件：-g 参数缺失、键名非 repo.packagist（单数小写带点）、url 未以 / 结尾且 type 值错误；composer 静默忽略，不报错不提示也不覆盖旧配置。
composer config -g repo.packagist 命令为什么没生效？
根本原因不是网络卡，而是命令写错三个硬性条件，Composer 会静默忽略——不报错、不提示、也不覆盖旧配置。
-
-g缺不得：没加就只改当前项目，换目录或 CI 流水线里完全无效 - 键名必须是
repo.packagist（单数、小写、带点、不能是repos.packagist或packagist.org） -
composer是 type 值，不是可选参数；URL 必须是 HTTPS 且以/结尾（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌）
验证是否真生效，只认这一条命令：composer config -g repo.packagist。输出应为完整 URL 字符串或类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、Key not found 都说明没写进去。
私有仓库为什么总是被 packagist.org 覆盖？
Composer 不 fallback，它按 repositories 数组从上到下**线性短路匹配**：第一个能解析出包名的仓库就停，后面全跳过。你配了私仓却装了官方版，八成是顺序或开关没关对。
- 私有仓库项必须放在
repositories数组**第一位**，类型写"type": "composer"或"type": "vcs" - 必须显式禁用官方源：
{"packagist.org": false}单独作为一项，放在repositories数组里（不能塞进某个仓库对象里，也不能放config下） - 如果还想保留 packagist 作后备，得在数组末尾加
{"packagist.org": true}，而不是再写一条{"type": "composer", "url": "https://packagist.org"}—— 后者会冲突报错
注意：repositories 必须是 JSON 数组（[]），不是对象（{}）。写成对象会导致只生效最后一项，且无任何警告。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
vcs 类型仓库 require 不到包？常见结构陷阱
"type": "vcs" 看似简单，但 Composer 实际行为依赖远程仓库结构和元数据，不是 URL 对了就能装。
- Git 仓库根目录下必须有合法
composer.json，其中name字段格式必须是vendor/name（如acme/internal-tool），单段名（internal-tool）直接失败 - 若 require 版本是
"^1.0"，则对应 Git tag（如v1.0.0）下的composer.json中version字段必须严格等于"1.0.0"，否则该 tag 不会被识别 - HTTPS 私仓必须走
auth.json，权限设为600；不能把 token 拼进 URL（https://token@...），也不能写进composer.json - SSH 方式（
git@gitlab.com:org/pkg.git）要求当前用户已将私钥加载进ssh-agent，否则卡在cloning into
调试时跑 composer install -vvv，搜日志里 Reading repository 后是否跟你的 URL；再用 composer show acme/internal-tool 看是否列出——没列出来，基本就是 name 或 version 不匹配。
镜像源和私仓混用时最易忽略的权限与作用域
全局镜像（composer config -g）在团队协作和 CI 中极易失效，因为配置只属于当前 shell 用户，而宝塔、GitHub Actions、Docker 容器常以不同用户运行。
- CI 流水线里别信全局配置，进项目根目录后执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），它会安全追加进composer.json的repositories字段 - 私仓认证凭据必须放
auth.json，且 Linux/macOS 下权限必须是600；权限不对，Composer 静默跳过，连 warning 都不给 -
auth.json可放在项目根目录（与composer.json同级）或$COMPOSER_HOME目录；前者可 Git 跟踪（敏感信息需 .gitignore），后者对所有项目生效但不可共享 - Satis 这类服务不是“开箱即用”的代理，它只静态生成
packages.json；包进不进索引，全看satis.json里有没有明确声明require或packages列表
真正麻烦的从来不是怎么配，而是配完不验证、不测权限、不查日志——结果问题堆到上线前才爆发。
