虚拟机中composer config -g常失效，因用户权限（如root写入但www-data读取）、非交互式shell导致HOME错乱、基础镜像缺curl/openssl致HTTPS静默失败；推荐用COMPOSER_REPO_PACKAGIST环境变量强制生效，并在Docker/WSL2等多层环境中分别配置。
虚拟机里改 Composer 镜像源，不能只跑一条 composer config -g 就完事——因为镜像源配置会被容器层、用户权限、非交互式 shell 三重覆盖，实际运行时大概率还是连 packagist.org。
为什么 composer config -g 在虚拟机里经常失效
常见错误现象：在 VirtualBox/VMware/WSL2 虚拟机中执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，再运行 composer install 却仍卡在境外源下载；或者 CI 流水线里提示 “Could not fetch packages.json”。
- 虚拟机中常以
root用户执行命令，但 PHP 进程（如 Apache 或 CLI）实际以www-data、nginx或普通用户身份运行，~/.composer/config.json写入的是 root 家目录，其他用户根本读不到 - Ansible、Vagrant provision 或 shell 脚本默认使用非登录 shell，
HOME环境变量可能未正确解析，导致composer config -g写入路径错乱（比如写到/root/.composer却期望在/home/vagrant/.composer） - 某些基础镜像（如 Alpine）没装
curl或openssl，composer无法验证 HTTPS 证书，直接 fallback 到官方源且不报错
用 COMPOSER_REPO_PACKAGIST 环境变量强制生效
这是最轻量、最可靠的方式，绕过用户级配置文件，直接注入运行时行为。适用于 Vagrant、Ansible、systemd 服务或手动启动的 PHP 进程。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 在虚拟机中全局生效：向
/etc/environment追加一行COMPOSER_REPO_PACKAGIST=https://mirrors.tencent.com/composer/，然后重启 shell 或执行source /etc/environment - 仅对当前会话有效：
export COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ - 在 systemd service 文件中添加：
Environment=COMPOSER_REPO_PACKAGIST=https://packagist.phpcomposer.com - 注意：该变量只影响 Packagist 主源，不影响自定义 repo（如私有 Git 包），那些仍需靠
composer config显式设置
在 Docker + 虚拟机混合场景下必须同步两层配置
如果你在 WSL2/VirtualBox 里跑 podman-compose 或 docker-compose，那么“虚拟机内”和“容器内”是两个独立环境，镜像源要分别配。
- 虚拟机系统层：确保
/etc/containers/registries.conf（Podman）或/etc/docker/daemon.json（Docker）已设国内 registry，否则php:8.2镜像拉取就慢 - 容器内 Composer 层：不能依赖宿主机的
config.json，必须在Dockerfile中提前写入，例如：RUN composer config -g repo.packagist composer https://mirrors.ustc.edu.cn/composer/ - 更稳妥的做法是在
docker-compose.yml的 service 下加环境变量：environment: { COMPOSER_REPO_PACKAGIST: "https://mirrors.aliyun.com/composer/" } - Alpine 基础镜像务必先装依赖：
RUN apk add --no-cache curl openssl，否则 HTTPS 请求会静默失败
自动化脚本检测镜像可用性再写入
硬编码一个镜像地址风险高——阿里云源某天维护，整个构建就卡住。脚本应探测 HTTP 状态码并 fallback。
- 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json检查是否返回200 - 失败则试腾讯云：
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.tencent.com/composer/packages.json - 都失败才回退到官方源，并记录警告日志
- 写入时用
composer config --global repo.packagist，不要用--unset，避免清空用户已配置的私有 repo - 脚本开头加
set -e，但对curl行必须加|| true，否则探测失败直接退出
真正麻烦的不是“怎么配”，而是“谁在哪个上下文里读这个配置”。虚拟机里用户、服务、容器、CI runner 各跑各的 HOME 和 PATH，漏掉一层，镜像源就形同虚设。动手前先 ps aux | grep php 看进程属主，再 echo $HOME 和 composer config -g --list 对齐路径，比反复重试高效得多。
