如何备份Composer配置文件（备份方案）-composer-PHP中文网

composer全局配置文件必须用composer config --global --list确认路径后备份，因其位置受composer_home环境变量影响且新版只认config.json，默认不存在；硬编码路径易失败。

如何备份composer配置文件（备份方案）

Composer 配置文件本身不包含项目逻辑，但一旦丢失或损坏，会影响全局行为（如镜像源、认证凭据、插件配置等），所以必须单独备份——它不能靠 composer.json 或 git 覆盖。

不同系统、不同安装方式下，Composer 全局配置位置不统一，直接硬编码路径容易失败：

composer config -g --list 是唯一可靠方式，它会输出实际生效的配置文件路径（比如 /home/user/.config/composer/config.json 或 /home/user/.composer/config.json）
旧版 Composer（~/.composer/config.json，新版（≥2.0）默认迁移到 ~/.config/composer/config.json
若执行 composer config -g --list 报错“Could not find config file”，说明尚未初始化全局配置，此时可跳过备份，或先运行 composer config -g github-oauth.github.com "xxx" 生成一个

Composer 的全局配置不只是 config.json 一个文件，还包括：

auth.json：存储私有仓库 token、OAuth 凭据，权限敏感，必须一起备份
keys/ 目录（如有）：存放 GPG 密钥，用于验证包签名
整个 .composer/ 或 .config/composer/ 目录才是完整单元，只复制单个 config.json 会导致后续 composer global install 失败

推荐命令：cp -r ~/.config/composer ~/backup/composer-global-$(date +%Y%m%d)（Linux/macOS）；Windows 用户请用 robocopy 而非 copy，避免长路径和权限截断。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

很多脚本用固定文件名（如 config.json.bak）覆盖旧备份，灾难发生时可能拿到的是上周的配置：

时间戳必须嵌入目录名，而不是文件名后缀——因为 auth.json 和 config.json 需保持同级关系
不要用 $(date +%s)（秒级），CI 环境并发执行时可能冲突；改用 $(date +%Y%m%d_%H%M%S) 更安全
加一层存在性检查：[ ! -d ~/backup/composer-global-$(date +%Y%m%d_%H%M%S) ] && cp -r ~/.config/composer ~/backup/composer-global-$(date +%Y%m%d_%H%M%S)

在 GitHub Actions、GitLab CI 等环境里，~/.config/composer/ 默认不存在，也不会自动创建，所以：

不能假设 composer config -g 总是成功，需前置判断：if [ -d "$HOME/.config/composer" ]; then cp -r "$HOME/.config/composer" "$BACKUP_DIR/"; fi
CI 中常用 COMPOSER_HOME 环境变量重定向配置路径，备份前必须检查该变量是否设置，否则会漏掉真实位置
如果用了 composer self-update，记得也备份 composer.phar 本身——它的版本决定了 config.json 的解析规则，尤其跨大版本（1.x → 2.x）时

真正麻烦的不是备份动作本身，而是恢复时发现 auth.json 权限不对（必须 600）、keys/ 缺失导致 verify 失败，或者 COMPOSER_HOME 没还原导致新命令仍读旧位置——这些细节不写进备份脚本，就等于没备。