私有包源配置本身不能自动备份，真正需备份的是composer.json中的repositories声明、auth.json凭据文件及satis等服务端生成的packages.json和dist包；漏备任一环节均会导致composer require静默失败或401错误。
私有包源配置本身不能“自动备份”，真正要备份的是 composer.json 中的 repositories 声明、auth.json 凭据文件，以及可能存在的本地镜像数据（如 Satis / Private Packagist 的生成目录）。 直接对“源”做备份没意义——它只是个声明或服务地址；真正会丢、会错、会泄露的，是这些配置和凭据。
备份 composer.json 里的 repositories 声明
项目级私有源必须写在项目根目录的 composer.json 中，且是 JSON 数组。漏备或误删会导致 composer require 静默失败（报 Could not find package 而不提示源问题）。
- 确保
composer.json本身纳入 Git 版本控制——这是最基础、最有效的“备份” - 若用多环境（dev/staging/prod），不同分支的
repositories内容可能不同，需确认当前分支的声明是否完整 - 禁止把
repositories写成对象（如{"my-repo": {...}}），必须是数组：[{"type":"vcs","url":"git@..."}]，否则 Composer 解析失败但不报错 - CI/CD 流水线中若动态注入
repositories（如 via env var + jq patch），备份时得一并存下该 patch 脚本或模板
备份 auth.json 及其权限
auth.json 是唯一合法存放凭据的位置，且权限必须为 600。权限不对（如 644）时，Composer 会静默忽略，不报错也不提示——这是最常踩的坑。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 备份路径：项目根目录下的
auth.json（仅影响当前项目）或全局$COMPOSER_HOME/auth.json（通常是~/.config/composer/auth.json或~/.composer/auth.json） - 备份前务必运行：
chmod 600 auth.json，再复制；恢复后也必须重设权限 - 不要硬编码 Token 或密码到
composer.json或 URL 里（如https://token:x-oauth-basic@github.com/...），这等于公开泄露 - 若用 SSH 密钥方式，备份的是密钥文件（
~/.ssh/id_rsa）而非auth.json，此时auth.json可为空
备份私有源服务端数据（Satis / Toran / 自建 Composer Server）
如果你搭了 Satis、Private Packagist 或自建的 Composer HTTP 源，它的“源”本质是静态 JSON 文件（如 packages.json）和 dist 包归档。这些才是真需要定期备份的数据。
- Satis 默认构建目录（如
web/）下所有内容都要备份：packages.json、include/all$xxx.json、dist/下的 zip/tar 包 - 备份命令示例：
tar -czf satis-backup-$(date +%F).tar.gz -C /var/www/satis web/ - 注意：Satis 构建过程依赖
composer.json和 Git 仓库可访问性，备份只是快照，恢复后仍需能重新php bin/satis build - 若用 Docker 部署（如
composer/satis），备份应包含挂载卷中的output/目录，而非容器内临时文件系统
真正容易被忽略的不是“怎么备份”，而是“备份后是否验证过恢复路径”。比如 auth.json 权限错、repositories 数组格式错、Satis 备份缺 dist/ 导致 install 时 fallback 到 Git 克隆失败——这些都不会在备份时暴露，只会在某次 composer update 时突然中断。
