Composer config -g repo.packagist 不生效是因为必须同时满足三个硬性条件：键名严格为单数 repo.packagist、第二参数必须显式写 composer（type 值）、URL 必须以 / 结尾，任一缺失均静默回退官方源且不报错。
composer config -g repo.packagist 为什么总不生效
这条命令不是“执行完就完事”，它必须同时满足三个硬性条件，缺一就会静默失败——不报错、不提示、不 fallback，Composer 自动退回 https://repo.packagist.org。
常见失效原因：
-
repo.packagist写成repos.packagist（多一个 s）或repositories.packagist.org（新版键名已弃用），Composer 2.2+ 直接忽略 - 漏掉中间的
composertype 值：命令必须是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，少composer就 fallback - URL 缺末尾斜杠：
https://mirrors.aliyun.com/composer会拼出/composerpackages.json，返回 404，Composer 自动弃用该镜像 - 执行用户 ≠ 运行用户：你在终端用
root配了，但宝塔后台以www用户运行，CI 用runner用户构建，它们读不到你的配置
验证是否真写入：composer config -g repo.packagist 输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或报错，说明根本没落盘。
项目级配置怎么安全追加而不覆盖私有源
全局配置靠不住，项目级才是团队协作和 CI 的事实标准。但直接手写 "repositories" 容易出错，尤其当已有私有源时。
推荐做法是进项目根目录后运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会：
- 自动检测
composer.json中是否存在"repositories"字段 - 若为对象（如
"repositories": {}），则安全 merge 进"packagist"子项，不覆盖已有私有源 - 若为数组（如
"repositories": []），命令会失败——需先手动改成空对象再运行 - 不会改动其他字段，也不破坏 JSON 格式
注意："packagist.org": false 必须作为 "repositories" 数组里的独立对象项，不能嵌套，也不能拼成 "packagist" 或 "packagist.com"；否则整个官方源被彻底关闭，镜像不可用时直接失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Docker 构建中 vendor 层缓存总失效的根本原因
根本不是 Composer 的问题，而是 Docker 层依赖链被破坏。只要 COPY . . 出现在 composer install 之前，哪怕只改了一个 README.md，Docker 就丢弃所有后续层缓存，包括 vendor/ 目录。
正确顺序必须是：
-
COPY composer.json composer.lock ./—— 这是缓存判断的唯一输入，且两个文件必须已提交 Git，不能被.dockerignore过滤 -
RUN composer install --no-dev --no-scripts --optimize-autoloader --no-interaction --prefer-dist—— 所有参数服务于确定性 -
COPY . .—— 放最后，同时确保.dockerignore包含/vendor，防止覆盖
额外风险点：--mount=type=cache,id=composer-cache 在 CI 多 job 并发时易冲突，不同 PHP 版本 job 共享同一 cache mount 可能导致平台要求不兼容；更可控的做法是用 actions/cache 缓存 ~/.composer/cache 目录，或宿主机挂载。
换镜像后仍卡在 “Loading composer repositories” 怎么排查
这不是镜像宕机，而是请求根本没发到镜像站——大概率是项目级 "repositories" 配置覆盖了全局设置，或 composer.json 里写了 "packagist.org": false 这类禁用语句。
三步定位：
- 查配置层：
composer config -g repo.packagist和composer config repo.packagist（无-g）分别看输出，确认哪一层在起作用 - 查项目定义：
composer config repositories，如果输出里还有https://repo.packagist.org，说明项目配置正在接管 - 查元数据可达性：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200 OK才算服务正常；再对比 provider 文件如https://mirrors.aliyun.com/composer/p2/laravel/framework/10.0.0.json，若官方存在而镜像 404，说明同步延迟，可临时切中科大源
复杂点在于：Composer 3.x+ 把 Packagist 元数据源硬编码为 https://repo.packagist.org，改 "repositories" 数组完全无效——它只影响非 packagist 类型的私有源。真正覆盖元数据请求路由的，只有 composer config -g repo.packagist 这一条命令。
