不生效。项目级repositories字段优先级永远高于全局配置，只要存在就会完全忽略repo.packagist的全局设置；验证需运行composer config repo.packagist（无-g），若输出非空即说明已被覆盖。
composer.json里写了"repositories"字段，全局镜像还生效吗
不生效。项目级 repositories 字段优先级永远高于全局配置，只要它存在，Composer 就完全忽略 repo.packagist 的全局设置。
常见误操作是：先配了全局镜像，再在 composer.json 里手动加了一段空 "repositories": [] 或错误格式的私有源——结果全局配置被静默屏蔽，下载又变慢，却查不出原因。
- 验证方式：运行
composer config repo.packagist（无-g），如果输出非空，说明项目级配置已覆盖全局 - 若
composer.json中repositories是数组（[]），则无法通过composer config repo.packagist命令安全追加，必须先手动改为对象（{}） - “禁用 packagist.org”写法如
"packagist.org": false或"packagist": false会彻底切断所有镜像回退路径，一旦镜像临时不可用，composer install直接失败
多环境配置（dev/staging/prod）下怎么避免镜像冲突
镜像本身不区分环境，但 composer.json 中的 repositories 若硬编码不同 URL（比如 dev 指向内网私有源，prod 指向阿里云镜像），会导致 composer install 行为不一致，甚至因锁文件 hash 不匹配而报错。
推荐做法是：只在 composer.json 中声明一个稳定、全环境可用的镜像源（如 https://mirrors.aliyun.com/composer/），把环境差异交给 require-dev 和 config.platform 控制，而非镜像地址。
- CI/CD 流水线中不要用
--repository-url临时换源——它会绕过composer.lock的校验逻辑，导致本地与线上依赖不一致 - 若必须用私有源（如公司 Nexus），应统一配置为 type
composer+ 公开可访问的 URL，并确保其元数据结构与 packagist 镜像兼容 -
composer.lock文件必须提交 Git；它记录的是包的实际下载地址和 hash，一旦镜像变更，旧 lock 文件可能指向已失效的路径
为什么换镜像后 composer install 还卡在 “Resolving dependencies”
这不是镜像问题，而是依赖解析阶段——这个阶段根本不走网络，纯本地计算。镜像只影响后续的 ZIP 包下载速度。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
典型诱因集中在 composer.json 写法上，尤其多环境场景下容易叠加恶化：
-
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"这类宽泛约束，会让 Composer 在数百个 PHP 版本组合间暴力试探 -
"minimum-stability": "dev"开启后，每个包都尝试拉取dev-main、dev-develop等不稳定分支，候选版本数指数级增长 - 多个环境共用同一份
composer.json，但通过脚本动态注入require-dev，导致每次install实际执行的是update逻辑
解决办法：删掉 vendor 和 composer.lock，改用 composer install --no-dev --prefer-dist -o 强制跳过解析阶段直接装锁文件。
宝塔、Docker、CI 中 composer.json 配置的坑
这些环境共同特点是：运行用户 ≠ 配置用户，且 ~/.composer/config.json 往往不可靠或根本不存在。
例如宝塔后台「一键部署」以 www 用户运行，但你是在 root 下执行的 composer config -g；Docker 构建时容器内没有 ~/.composer 目录；GitHub Actions 默认用 runner 用户，且每次都是干净环境。
- 唯一稳妥方案：在项目根目录执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g），让配置落地到composer.json - CI 脚本里别写
composer config -g，改用composer config repo.packagist+git add composer.json提交变更 - Dockerfile 中应在
RUN阶段前就 COPY 已含正确repositories的composer.json，而不是构建时再配
真正容易被忽略的点是：composer.json 里的 repositories 必须是对象（{}），不是数组（[]）——前者支持键名定位追加，后者会直接报错中断 CI 流程。
