结论是自定义源分中文镜像和企业内部源两类，配法不同且混用会出错；composer config -g repo.packagist不生效主因是键名必须为单数repo.packagist、type值必须显式写composer、url须以https://开头且末尾带/，三者缺一即静默回退官方源。
直接说结论：自定义源分两类——中文镜像（加速公开包）和企业内部源（托管私有包），配法完全不同，混用会出错；关键不是“怎么写”，而是“写在哪”和“怎么关默认源”。
composer config -g repo.packagist 命令为什么总不生效？
90% 的失败不是网络问题，是命令敲错了三个硬性条件：
-
repo.packagist必须是单数repo，写成repos.packagist或packagist.org都静默失效 -
composer是必须显式写出的type值，不能省略，也不能当注释看 - URL 必须以
https://开头，且末尾带/，比如https://mirrors.aliyun.com/composer/✅，少斜杠就拼成/composerpackages.json导致 404
验证是否成功：运行 composer config -g repo.packagist，正确输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null 或报错，说明没写对。
项目级配置比全局更可靠，但 repositories 写法有陷阱
进项目根目录执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意去掉 -g），它会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"。
但前提是原 composer.json 里 "repositories" 是对象（如 "repositories": {}），不是数组。如果是数组格式，命令会报错或覆盖整个数组，导致已有的私有源丢失。
已有私有源时，别手动改 composer.json，用命令追加更安全：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确认当前结构：
cat composer.json | jq '.repositories' - 如果输出是
{}或null，直接跑上面那条composer config命令 - 如果已是数组，得先转成对象再操作，否则容易误删
企业私有源 type 写错会导致静默失败
私有 Git 仓库（如 GitLab）和私有 Composer 服务（如 Satis、Private Packagist）必须用不同 type：
-
type: vcs→ 对应 Git/SVN 地址，Composer 会 clone 并读取其中的composer.json，适合单个私有库 -
type: composer→ 对应提供packages.json的 HTTP 服务，比如阿里云镜像、Satis 页面，适合托管多个包
常见错误：把 Satis 服务地址当成 vcs 配，结果 Composer 尝试用 Git 协议去拉，报 Could not find package 这种笼统错误，实际根本没连上 HTTP API。
还必须显式禁用默认源，否则即使写了私有源，Composer 仍会先去 packagist.org 查一遍，可能装错版本：
- 全局禁用：
composer config -g packagist false - 项目级禁用：在
composer.json的repositories里加"packagist.org": false
换源后 still stuck at “Resolving dependencies”？和镜像无关
镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本可以确定是以下原因：
-
composer.json里 PHP 版本约束太宽，比如"php": "^7.4 || ^8.0"，让 Composer 尝试大量组合 - 大量未锁定的
dev-分支依赖，如"monolog/monolog": "dev-main" -
require-dev里塞了太多工具链（phpunit、phpstan、psalm混在一起）
这类问题换任何镜像都没用，得精简约束、锁定版本、拆分开发依赖。
