composer config -g repo.packagist 不生效，根本原因是三要素缺一不可：键名必须为单数 repo.packagist（非 repos）、type 值必须显式写 composer、url 必须以 https:// 开头且末尾带 /；任一缺失即静默回退至 packagist.org。
composer config -g repo.packagist 命令不生效？Fedora 下必须写对三要素
在 Fedora 上执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 却没效果，大概率不是网络或权限问题，而是命令漏了关键成分。Composer 2.x 在 Fedora（默认用 systemd-user + home directory ACL）下对配置校验更严格，缺一不可：
-
repo.packagist是唯一合法键名——写成repos.packagist（多 s）、packagist.org或mirror都静默失败 -
composer是必需的type值，不是可选参数，也不是注释；省略后直接 fallback 到https://packagist.org - URL 必须是 HTTPS 且末尾带
/，例如https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404
验证是否真写进去了：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报 Key not found 或只返回原始 URL 字符串（新版行为），都说明失败。
Fedora 用户常踩的权限和路径坑
Fedora 默认启用 home 目录加密（~/.local/share/containers/storage 之外的路径可能受 systemd-homed 约束），~/.composer/config.json 可能因 SELinux 或 home 加密无法写入。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确认 Composer 是否能读写全局配置目录：
ls -ld ~/.composer，若提示Permission denied，执行mkdir -p ~/.composer && chmod 700 ~/.composer - SELinux 拒绝写入时，临时测试用：
sudo setsebool -P httpd_can_network_connect 1（仅限开发机，生产环境需精确策略） - 检查 Composer 是否在正确用户上下文中运行：
id -un和ps -o user= -p $$应一致；若在 systemd service 或 cron 中调用，需显式指定--user或切换用户 - 别用
sudo composer config -g ...——这会写进 root 的/root/.composer/config.json，普通用户 shell 读不到
项目级配置比全局更可靠，尤其在 Fedora 容器或 Podman 场景
Fedora Workstation 常用 Podman 运行 CI 工具链，而容器内默认没有 ~/.composer，全局配置完全失效。项目级配置写进 composer.json，Git 可追踪、容器内外行为一致。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不带-g） - 该命令会自动识别
"repositories"结构：若原为对象，就写入"packagist"键；若为数组，则追加新项，不破坏私有源 - 切忌手动写
"packagist.org": false——这会导致php、ext-json等基础约束校验失败 - 改完立刻运行：
composer update --lock，确保composer.lock记录的是镜像源地址，而非官方源
换源后仍卡在 “Resolving dependencies”？和镜像无关
镜像只加速元数据拉取和 ZIP 包下载，不参与依赖解析。Fedora 上 composer update 卡在 Resolving dependencies 几十秒以上，基本可排除镜像问题：
-
composer.json中 PHP 版本约束太宽，如"php": "^7.4 || ^8.0 || ^8.1"，让 Composer 尝试大量组合 - 存在未锁定的
dev-分支依赖，如"monolog/monolog": "dev-main" -
require-dev里塞了太多工具包，尤其是已废弃的fxp/composer-asset-plugin（它绕过 Composer 镜像机制） - 用
-vvv运行composer update -vvv，观察日志中是否出现mirrors.aliyun.com—— 若出现，说明镜像已生效，问题在本地解析逻辑
真正容易被忽略的是：Fedora 默认启用 dnf-plugins-core 的 builddep 机制，某些 PHP 扩展（如 ext-intl）若未通过 dnf install php-intl 安装，Composer 会反复尝试降级匹配，拖慢解析过程。
