codespaces 中 composer config -g 无效，必须通过 devcontainer.json 的 postcreatecommand 修改项目级 composer.json 并更新 composer.lock；同时需在 devcontainer.json 中配置 php 扩展和 composer_memory_limit=-1 以避免依赖解析卡住。
composer config 命令在 Codespaces 里直接跑是无效的——它只改本地用户配置，而 Codespaces 每次重建容器都会重置全局配置。必须把镜像源写进 devcontainer.json 或项目级 composer.json，否则每次打开都是官方源。
devcontainer.json 中注入镜像源（推荐）
Codespaces 启动时会执行 postCreateCommand，但这个阶段 composer config -g 不生效（权限/路径问题），更可靠的方式是：在 devcontainer.json 的 features 或 customizations 里预置配置。
- 用
"ghcr.io/devcontainers/features/composer:1"功能时，它不自动设镜像；需额外加customizations执行初始化命令 - 推荐写法：在
devcontainer.json中加入"postCreateCommand": "composer config repo.packagist composer https://mirrors.aliyun.com/composer/" - 注意：这里不能带
-g，否则写入的是容器内 root 用户的全局配置，而 Codespaces 默认以非 root 用户运行终端，实际不生效 - 这条命令会直接修改项目根目录下的
composer.json，生成"repositories": {"packagist": {...}}，所有成员开箱即用
为什么 composer config -g 在 Codespaces 里总失败？
不是命令写错，是环境限制：
-
~/.composer/config.json在容器重启后丢失（除非挂载 volume，但 Codespaces 默认不挂载） - 即使临时写入，后续
composer install运行时用的是项目用户（如codespace），而-g写的是 root 的配置，权限隔离导致读不到 - 验证方式：进终端执行
composer config -g repo.packagist，大概率返回null或空对象，说明没落盘成功 - 别试
sudo composer config -g—— Codespaces 禁用 root 密码，且 sudo 不保证配置持久化
项目级配置 + composer.lock 必须配套更新
仅改 composer.json 不够，composer.lock 里记录的下载地址仍是旧源，会导致首次 install 卡住或 404。
- 执行
composer update --lock（或删掉composer.lock后重新composer install）强制重生成 lock 文件 - 如果项目已有私有仓库配置，确认
"repositories"是对象而非数组——否则composer config repo.packagist ...会覆盖整个字段，丢掉私有源 - CI 流水线中若用
composer install --no-interaction，确保composer.lock已含国内源元数据，否则仍走官方域名解析
换源后仍卡在 Resolving dependencies？和镜像无关
镜像只加速包下载，不优化依赖解析。Codespaces 里卡在这一步，90% 是以下原因：
- PHP 扩展缺失：
mbstring、xml、zip任一未启用，composer update会静默卡住或报错不明确 -
composer.json里写了过宽的版本约束（如"^1.0 || ^2.0"），触发复杂回溯计算，小内存 Codespaces 容易超时 - 没配
COMPOSER_MEMORY_LIMIT=-1，默认内存限制在 1.5GB 左右，大型项目解析失败 - 解决方法：在
devcontainer.json的environment字段加"COMPOSER_MEMORY_LIMIT": "-1"，并在features中显式启用所需 PHP 扩展
composer.json，把扩展和内存限制写进 devcontainer.json，然后让 postCreateCommand 跑一次 composer update --lock。
