直接写 /etc/composer/config.json 实现真全局镜像覆盖，因 Composer 2.2+ 支持系统级配置，优先级最高、不依赖用户 home 目录；而 ~/.composer/config.json 在批量部署中常因执行用户与 PHP 进程用户（如 www-data）不一致导致失效。
直接写 /etc/composer/config.json，别碰 ~/.composer/config.json —— 批量部署时后者几乎必然失效。
为什么 composer config -g repo.packagist 总是不生效
这条命令本身没错，但执行用户和 PHP 进程用户不一致才是真问题。比如用 sudo composer config -g，配置进了 /root/.composer/config.json；而 Web 请求实际由 www-data 用户跑，它根本不会读 root 的家目录。
- 用
sudo -u www-data composer config -g也常失败：目标用户 shell 可能被设为/usr/sbin/nologin，Composer 加载器起不来 -
getent passwd www-data | cut -d: -f6查HOME路径，再ls -ld看是否可写 —— 很多容器或最小化系统里/var/www根本没.composer目录 - 项目级
composer.json里只要出现"repositories"字段（哪怕只写了{"packagist.org": false}），全局配置就彻底被覆盖
用 /etc/composer/config.json 实现真全局生效
Composer 2.2+ 支持系统级配置，路径固定、优先级最高、不依赖任何用户 HOME。这才是批量下发（Ansible/SaltStack/shell 脚本）唯一稳的方案。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 内容必须是合法 JSON，
"repositories"下只保留"packagist.org"一项，不要加多余逗号或注释 - 权限必须是
644，属主root:root：sudo chmod 644 /etc/composer/config.json && sudo chown root:root /etc/composer/config.json - 验证方式不是看 root 的输出，而是用目标用户查：
sudo -u www-data composer config repo.packagist，输出应为https://mirrors.aliyun.com/composer/ - 若报错 “command not found” 或输出空，先确认
sudo -u www-data composer --version是否 ≥ 2.2；低于此版本需升级
composer clear-cache 必须跟上，否则镜像形同虚设
很多人配完镜像源，composer install 日志里还是出现 https://packagist.org/packages.json —— 不是配置没写对，是旧缓存还在用海外地址索引。
-
composer clear-cache必须以实际运行用户执行：sudo -u www-data composer clear-cache - 缓存路径默认在
~/.cache/composer，但若www-data的HOME是/var/www，就得确保该路径可写 - 项目根目录下若有
vendor/，建议连带删掉再重试，避免残留的composer.lock绑定旧源 -
composer diagnose报 “Could not fetch packages.json”，先检查sudo -u www-data php -i | grep disable_functions | grep proc_open—— 若命中，PHP 禁用了关键函数，镜像再快也没用
最易忽略的一点：哪怕 /etc/composer/config.json 写对了、clear-cache 也执行了，只要项目 composer.json 里有 "repositories" 块，镜像就自动失效。上线前务必 grep -A5 '"repositories"' composer.json 扫一遍。
