COMPOSER_HOME 由环境变量控制，优先级最高，路径需手动创建且不可为空；设置后全局配置、缓存、全局包均落于此，但不自动迁移旧 ~/.composer 数据。
Composer 的 COMPOSER_HOME 目录不是“设置”出来的，而是靠环境变量控制的——你改了环境变量，它就认新路径；不设，它就用默认值。
COMPOSER_HOME 环境变量怎么生效
Composer 启动时会优先读取 COMPOSER_HOME 环境变量，如果存在且是合法路径，所有全局配置（auth.json）、缓存（cache/）、全局包安装目录（vendor/）都会落到这个目录下。它不会自动创建，路径必须手动建好，否则 Composer 会报错或退回到默认行为。
常见错误现象：Could not write to /home/user/.composer/cache/repo/https---packagist.org/ —— 实际是权限问题，但根源常是 COMPOSER_HOME 指向了一个没写权限或根本不存在的目录。
- Linux/macOS：在
~/.bashrc或~/.zshrc中加export COMPOSER_HOME="/path/to/my-composer-home"，然后source加载 - Windows（CMD）：用
setx COMPOSER_HOME "D:\my-composer"（注意双引号不能少） - Windows（PowerShell）：用
$env:COMPOSER_HOME="D:\my-composer"，但只对当前会话有效；永久需改系统环境变量 - 路径末尾不要加斜杠，
COMPOSER_HOME值本身不参与拼接逻辑，加不加不影响，但统一不加更稳妥
为什么改了 COMPOSER_HOME 还看到 .composer 目录
旧的 ~/.composer 不会自动迁移，也不会被忽略——Composer 只在初始化时检查 COMPOSER_HOME，之后完全无视旧路径。但如果你之前用过全局命令（如 composer global require），那些包仍留在 ~/.composer/vendor，而新命令会往新路径装，造成“两套全局包”并存。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
使用场景：CI/CD 流水线中隔离缓存、多用户共享机器时避免冲突、容器内固定非家目录路径。
- 确认当前生效路径：运行
composer config --list --global，第一行显示的home值就是当前COMPOSER_HOME解析结果 - 想彻底切换，得手动把
~/.composer/auth.json和~/.composer/composer.json复制过去，并确保新路径下有auth.json（否则私库认证会失败） - 别直接删
~/.composer，除非你确认里面没重要凭证或自定义配置
COMPOSER_HOME 和 COMPOSER_CACHE_DIR 的关系
COMPOSER_CACHE_DIR 是独立于 COMPOSER_HOME 的环境变量，优先级更高。一旦设置了它，缓存就会强制落到该路径，不管 COMPOSER_HOME 是啥。其他东西（配置、全局 vendor）仍走 COMPOSER_HOME。
性能影响：把缓存放到 SSD 或内存盘（如 Linux 的 /dev/shm）能明显加快 install/update；但要注意 COMPOSER_CACHE_DIR 路径必须可写，且不能是符号链接（某些版本会拒绝）。
- 设置缓存单独路径：
export COMPOSER_CACHE_DIR="/tmp/composer-cache" - 验证是否生效：
composer config --list --global | grep cache-dir应该显示你设的值 - 如果同时设了
COMPOSER_HOME和COMPOSER_CACHE_DIR，前者管配置和全局包，后者只管cache/子目录，互不干扰 - Windows 上路径含空格（如
C:\Program Files\...）极易出错，建议避开
真正容易被忽略的是权限和初始化时机：环境变量必须在运行 composer 命令前就加载好；新 COMPOSER_HOME 下的 auth.json 如果缺失或格式错，私库请求会静默失败，而不是报错提示。
