azure上中文镜像易失效是因权限隔离导致全局配置不生效，必须用项目级配置：composer config repo.packagist composer https://mirrors.aliyun.com/composer/，并运行composer update --lock；ci/cd中应使用--repository-url临时指定，而非依赖全局配置。
为什么Azure上配中文镜像容易失效
不是镜像源不行，是Azure Web Apps默认用www-data或appservice用户执行Composer，而你本地composer config -g配的是自己账户的~/.composer/config.json——它根本读不到。CI/CD、Kudu构建、甚至宝塔面板都存在同样问题：全局配置被权限隔离，静默回退到https://packagist.org。
Azure部署时必须用项目级镜像配置
进项目根目录（含composer.json），运行这条命令：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动向composer.json的repositories字段安全追加条目，不覆盖已有私有源。注意：
- 如果
"repositories": {}是空对象，命令能正确转为数组并插入"packagist"项 - 如果
"repositories"已是数组格式，命令会追加到末尾，不会破坏Git仓库或私有包源 - 千万别手动写
"packagist": false——这会导致ext-json等基础扩展校验失败 - 改完立刻运行
composer update --lock，让composer.lock记录新源地址
CI/CD流水线里别信全局配置
Azure DevOps或GitHub Actions中，硬写composer config -g大概率无效。更可靠的做法是临时指定镜像：
composer install -vvv --repository-url=https://mirrors.aliyun.com/composer/
-vvv能打印真实请求URL，确认是否走镜像；--repository-url只本次生效，不改任何配置。适用于：
- Docker构建阶段，避免镜像源硬编码导致维护风险
- 临时调试，快速验证是否真卡在下载环节
- 多环境部署（测试/预发/生产）需差异化源时
换源后仍卡在Resolving dependencies？和镜像无关
中文镜像只加速Downloading和Loading repositories阶段，不解决依赖解析本身慢的问题。Azure上卡在这里，常见真实原因：
-
"php": "^7.4 || ^8.0"这类宽泛约束，让Composer遍历大量候选版本 -
require-dev里没锁死phpunit/phpunit等开发依赖版本 - PHP版本与
platform配置不匹配，触发降级查找逻辑 - 内存不足（Azure默认128M），加
COMPOSER_MEMORY_LIMIT=-1再试
这些跟镜像源完全无关，但容易误判为“镜像没起作用”——实际是composer.json写法或平台配置需要收紧。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
