Composer中文镜像与nvm共存时，真正卡住的是路径、生效范围和缓存机制的隐性冲突：CI中全局配置因用户环境隔离而失效，必须用项目级composer config repo.packagist composer https://mirrors.aliyun.com/composer/并确保repositories为对象；Docker中nvm use需配合nvm alias default或改用node:x-slim基础镜像；换源后须clear-cache并重生成composer.lock。
Composer中文镜像和nvm共存时，真正卡住你的不是镜像本身，而是两者配置路径、生效范围和缓存机制的隐性冲突——尤其在多端构建（如CI/CD跑PHP+Node混合项目）中，composer install 和 npm install 会各自读取不同用户的配置，稍不注意就回退到官方源或旧Node版本。
composer config -g repo.packagist 为什么在CI里完全不生效
全局配置写在 ~/.composer/config.json，但CI runner（比如GitHub Actions的 ubuntu-latest）默认以全新用户运行，~ 是空目录，composer config -g 写进去的东西根本不存在。更糟的是，很多CI模板自带 composer.json 里的 "repositories": []，这会直接屏蔽全局设置。
- CI中必须进项目根目录，执行不带
-g的命令：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 如果项目
composer.json中repositories是数组（[]），该命令会报错；需先手动改成对象："repositories": {} - 提交修改后的
composer.json——这是唯一能让所有环境（本地、CI、Docker build）行为一致的方式
nvm use 在 Docker 构建阶段失效的典型原因
Docker 构建是分层执行的，每条 RUN 指令都启动新 shell，nvm use 只对当前 shell 生效，下一层就重置了。你在 Dockerfile 里写 RUN nvm use 18.19.0 && node -v 看起来输出正确，但紧接着的 RUN npm install 其实跑在默认 Node 上。
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
- 正确做法：用
nvm alias default 18.19.0，再source $NVM_DIR/nvm.sh，确保后续所有 shell 都继承默认版本 - 或者跳过 nvm，直接用
FROM node:18.19.0-slim基础镜像，更轻量、更确定 - 若必须用 nvm，把
source和alias写进.bashrc并在每个RUN前显式加载：RUN source ~/.bashrc && npm install
多端构建时 vendor/ 和 node_modules 缓存混用的风险
有些团队把 vendor/ 和 node_modules/ 都放进 CI 缓存，但这两者生命周期完全不同：Composer lock 文件 hash 依赖镜像源 URL，而 npm 的 package-lock.json 不校验 registry 地址。一旦镜像配置变更或本地换源，vendor/ 缓存可能含错误元数据，导致 composer install 报 hash mismatch 或 404。
- CI 缓存应分开管理：
composer install后只缓存vendor/，npm install后只缓存node_modules/ - 每次换镜像源后，必须加
composer clear-cache，并删掉composer.lock重新生成（尤其当repositories结构变更时） -
docker build阶段不要 COPYnode_modules/或vendor/——它们体积大、易污染，应该在容器内安装
最常被忽略的一点：nvm 和 Composer 都依赖环境变量 $HOME 定位配置，但 Docker 容器里 $HOME 可能未设或指向 /，导致 ~/.composer 或 ~/.nvm 实际写入失败。检查方式很简单：echo $HOME 和 ls -la $HOME 必须同时出现在构建日志里。
