答案是：composer config -g repo.packagist 静默失效主因是四条件未全满足——必须加-g、键名严格为单数repo.packagist、type值显式写composer、url用https且末尾带/；任一缺失即不报错但回退官方源。
配了但 composer install 还卡在 Loading composer repositories？不是镜像没生效，就是 WSL 的 DNS 缓存或项目级配置把它绕过去了。
为什么 composer config -g repo.packagist 总是静默失效
这条命令必须同时满足四个硬性条件，漏一个就写进错字段、不报错、不生效：
-
-g：必须加，否则只作用于当前项目目录，全局无效 -
repo.packagist：键名是单数，repos.packagist（多一个 s）会写进无效字段，查出来为空 -
composer：type 值必须显式写出，不能省略；composer config -g repo.packagist https://mirrors.aliyun.com/composer/缺 type，Composer 2.0+ 直接 fallback 回packagist.org -
https://mirrors.aliyun.com/composer/：协议必须是 HTTPS，末尾斜杠/不可少；少斜杠会导致请求路径拼成/composerpackages.json，返回 404 且不提示
验证是否真写入：运行 composer config -g repo.packagist，输出应为完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或报错都说明失败。
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
WSL2 下“配了但没用”的两个真实原因
即使 composer config -g repo.packagist 输出正确，执行 composer install 仍卡住，大概率是以下两者之一：
- DNS 缓存未刷新：PHP 的 cURL 复用系统 DNS 缓存，
mirrors.aliyun.com可能仍被解析到海外 IP。不用改系统 DNS，临时加环境变量即可：COMPOSER_IPV4=1 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 项目级
repositories覆盖全局：只要项目根目录composer.json里出现"repositories"字段（哪怕只有一行空数组[]），全局镜像立刻失效。删掉该字段或设为"repositories": null才能恢复
如何确认 Composer 真走的是镜像
别信 config -g 的输出，要看实际网络行为：
- 加详细日志跑一次：
composer update -vvv 2>&1 | grep mirrors.aliyun.com，有匹配行才说明请求发到了镜像站 - 或者运行
composer diagnose，看Repo packagist.org:后面显示的 URL 是不是你设的镜像地址 —— 注意它显示的仍是packagist.org这个名字，但 URL 已被替换 - 如果
diagnose显示的还是https://packagist.org，说明配置根本没加载，优先检查~/.composer/config.json文件权限（chown -R $USER ~/.composer）
最稳的组合不是换多个镜像源，而是 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ + COMPOSER_IPV4=1 + composer clear-cache 三者一起执行。缺一不可，尤其是 clear-cache —— WSL2 的缓存残留比 Windows 原生更顽固，不清理就容易复用旧的 packagist.org 元数据。
