composer config -g repo.packagist 未生效，根本原因是 composer 命令本身未被系统识别，需先确保 which composer 有输出、composer --version 可执行，即 PATH 已正确配置并重载 shell 配置（如 source ~/.zshrc），否则全局配置无法写入且 ~/.composer/config.json 不会被创建。
composer config -g repo.packagist 命令执行后没生效？
不是命令写错了，而是 composer config -g 只影响当前用户全局配置，但前提是 composer 命令本身能被 shell 正确识别。如果 which composer 无输出或报 command not found，那这步根本不会写入任何配置——~/.composer/config.json 文件甚至都不会被创建。
先确认 composer 可执行：运行 composer --version。失败就别急着配镜像，得回头检查 PATH 和二进制位置。
-
composer必须已正确安装到/opt/homebrew/bin/composer（Apple Silicon）或/usr/local/bin/composer（Intel） - 对应路径必须出现在
$PATH中：运行echo $PATH查看 - Zsh 用户务必编辑
~/.zshrc，加export PATH="/opt/homebrew/bin:$PATH"或export PATH="/usr/local/bin:$PATH"，然后执行source ~/.zshrc
阿里云镜像源地址该用哪个？
2026 年国内最稳的 Composer 镜像仍是阿里云，但旧地址 https://packagist.phpcomposer.com 已停用多年，强行配置会触发 404 或降级回官方源。新地址必须用：
https://mirrors.aliyun.com/composer/
执行命令时注意空格和引号：
- 全局设置（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否写入：
composer config -g repo.packagist应直接输出该 URL - 若项目里已有
composer.json且含repositories字段，它会优先于全局镜像，这是正常行为
为什么 composer install 还是从 packagist.org 下载？
常见原因不是镜像没配，而是缓存没清或锁文件残留。Composer 会优先读取 composer.lock 中记录的原始下载地址，哪怕镜像已生效。
- 先删掉
vendor/目录和composer.lock文件 - 再跑
composer clear-cache，确认输出 “Clearing cache (cache-dir)” - 最后执行
composer install -v，观察日志里出现的 URL 是否为mirrors.aliyun.com - 如果仍走官方源，检查项目根目录下是否有
composer.json里硬编码了"url": "https://packagist.org"—— 这种写法会覆盖全局镜像
~/.zshrc 改了但新开终端还是找不到 composer
Zsh 启动时只读一次 ~/.zshrc，改完不 source 或不新开终端，PATH 就不会更新。更隐蔽的问题是：有些终端 App（如 VS Code 内置终端、iTerm2 的某些配置）默认不加载登录 shell，导致 ~/.zshrc 被跳过。
- 新开终端后，先运行
echo $SHELL确认是/bin/zsh - 再运行
echo $PATH | grep -E "(homebrew|local/bin)"，看目标路径是否真在其中 - 如果不在，说明
source ~/.zshrc没执行，或终端启动方式绕过了它；可临时补一句source ~/.zshrc再试 -
which composer必须输出完整路径，否则所有后续操作都建立在错误前提上
真正卡住人的从来不是镜像地址输错，而是 composer 命令本身还没真正“活”在系统里。PATH、权限、shell 加载顺序，三者缺一不可。等 which composer 有输出、composer --version 有响应，再配镜像才谈得上“生效”。
