配置未生效需检查三要素：键名必须为repo.packagist（单数）、中间必须显式写composer（type值）、url须https且结尾带/；输出为空或仍为https://packagist.org说明未写入，应重新执行正确命令并验证。
composer config -g repo.packagist 输出为空或仍是 packagist.org 怎么办
说明：这条命令不报错，不代表写入成功。很多用户执行完 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为搞定了，结果 composer install 还是慢、超时、报 could not find package。
实操建议：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须用
composer config -g repo.packagist单独查值，不能只看命令是否返回空行——输出应为完整 URL 字符串或 JSON 对象（如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}） - 如果输出是
null、{}或"https://packagist.org"，说明配置根本没生效 - 常见失效原因：键名写成
repos.packagist或repository.packagist；中间漏掉composer类型值；URL 末尾缺/ - Windows 用户若提示
command not found，大概率是 PHP CLI 没进 PATH，或安装时未勾选“Add to PATH”
项目里有 repositories 字段，全局镜像还起作用吗
不起作用。Composer 的仓库加载顺序是硬编码的：项目级 composer.json > 全局 ~/.composer/config.json > 默认源。只要项目根目录的 composer.json 中定义了 "repositories" 数组（哪怕内容是空数组 []），全局配置就会被完全跳过。
实操建议：
- 想验证镜像是否真可用？临时绕过项目配置：运行
composer update --repository-url=https://mirrors.aliyun.com/composer/ - CI 脚本中不能依赖
--repository-url参数，因为composer create-project不支持-r；必须先composer config -g repo.packagist ...，再执行后续命令 - 团队协作推荐项目级配置：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会自动把镜像加到composer.json的repositories数组首位，不破坏已有私有源
私有仓库配置后 Composer 仍连 packagist.org 是为什么
私有仓库（如 Satis、Artifactory、Nexus）不是填个 URL 就能用。Composer 默认行为是先查 packagist.org，查不到才 fallback 到 repositories 列表——哪怕你 require 的包只存在于私有源，它也坚持先连外网。
实操建议：
-
repositories中每条记录的type必须是"composer"（不是"vcs"、"git"或留空） - URL 必须以
/结尾，否则 Composer 拼出的packages.json路径会 404 - 必须同级声明
"packagist.org": false，且键名严格为小写、带点、无复数："packagist.org"—— 写成"packagist"或"repositories.packagist"全无效 - 该配置只能写在项目级
composer.json中，不能放在全局config.json里
auth.json 域名 key 和仓库 URL host 不一致导致认证失败
Composer 读取 auth.json 时，会严格比对域名部分（host）和仓库 URL 的 host 是否完全一致，包括端口、子域、协议前缀。哪怕只差一个 www. 或端口号，认证就静默失败，报错却只显示 Could not fetch... 或 401 Unauthorized。
实操建议：
- 检查
auth.json中的 key 是否与仓库 URL 的 host 完全相同，例如仓库是https://packages.example.com/，则 key 必须是"packages.example.com"，不能是"https://packages.example.com"或"example.com" - 私有仓库用了非标准端口（如
:8081），key 必须包含端口："packages.example.com:8081" - 修改后运行
composer clear-cache，否则旧缓存可能让认证持续失败 - 调试时可加
-vvv参数：运行composer update -vvv，查看日志中实际请求的 host 和认证头是否匹配
composer config -g 输出、composer.json 结构、auth.json key 格式。
