答案是：composer config -g repo.packagist 总不生效主因是用户上下文错，配置写入当前用户家目录而php进程以www-data等其他用户运行，导致读不到；必须用实际执行用户配置或改用系统级/etc/composer/config.json。
配中文镜像不是执行一条命令就完事，关键得让真正跑 composer install 的那个 PHP 进程读到它——否则再快的镜像也白搭。
为什么 composer config -g repo.packagist 总是不生效
不是命令写错，而是用户上下文错了。运行 whoami 看当前是谁，composer config -g 只会写进该用户的 ~/.composer/config.json；如果你用 sudo composer config -g，配置就进了 /root/.composer/config.json，但 www-data 或 nginx 用户根本不会去读它。
- Web 场景下，PHP-FPM 通常以
www-data、nginx或自定义低权限用户运行，必须用对应用户执行配置，或改用系统级配置 - 验证实际生效路径：
composer config -g --global-config，它会输出正在读取的文件路径 - 如果输出是
/root/.composer/config.json，而你项目由www-data启动，那配置就是废的
推荐做法：直接写 /etc/composer/config.json
Composer 2.2+ 支持系统级配置，路径为 /etc/composer/config.json，优先级最高、不依赖用户 home、所有用户（包括 www-data）都认。适合生产环境和批量部署。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 创建目录并写入配置：
{ "repositories": { "packagist.org": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } } } - 设权限：
sudo chmod 644 /etc/composer/config.json && sudo chown root:root /etc/composer/config.json - 验证是否加载：
sudo -u www-data composer config repo.packagist，应输出镜像 URL - 若报错或为空，说明 Composer 版本低于 2.2，需先升级：
composer self-update
阿里云镜像 URL 必须严格匹配
少一个字符就静默回退到官方源，连错误都不报。最常踩的坑是键名、类型、URL 格式三者之一出错。
- 正确命令只有一种：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ -
repo.packagist是固定键名，写成repos.packagist、packagist.org或mirror都无效 -
composer是必须显式的type值，不能省略 - URL 必须以
https://开头，且结尾带/；少了斜杠，某些版本会拼出.../composer/packages.json导致 404 - 配完立刻清缓存：
composer clear-cache，否则旧缓存可能仍触发原始域名请求
项目级配置会完全覆盖全局镜像
只要项目根目录下的 composer.json 含 "repositories" 字段（哪怕只写了 {} 或 {"packagist.org": false}），全局配置就彻底失效。
- 快速检查：
grep -A5 '"repositories"' composer.json - 临时绕过项目配置：
composer config --unset repositories（仅当前项目） - CI/CD 中尤其要注意：同一台机器上不同项目可能互相污染，建议统一用系统级配置 + 显式
--no-plugins防第三方语言包干扰
真正卡住的地方往往不是镜像地址对不对，而是谁在读、从哪读、有没有被覆盖——尤其是 www-data 没 shell、/etc/composer/config.json 权限不对、或者项目里悄悄写了空 repositories，这三类问题占了线上故障的八成以上。
