私有包回滚关键在composer.lock控制、私有源稳定性及认证不中断：先用git checkout恢复历史lock文件，删vendor后执行composer install；降级单个包用composer require vendor/package:^x.x --with-all-dependencies；需确保私有源保留旧版本tarball或commit且认证有效。
私有包回滚不是“撤回发布”，而是让项目重新拉取旧版本的 tarball 或 git commit —— 关键在 lock 文件控制 + 私有源稳定性 + 认证不中断。
composer.lock 被改了，私有包就装不上旧版
你执行 composer install 后 vendor 里还是新包？大概率是当前 composer.lock 已被 composer update 或 CI 自动重写过，里面记录的是新版本的 dist/sha256 和 reference（git commit hash）。
私有包不像 packagist.org 那样有完整历史版本索引，它只提供你配置的 URL 所能解析到的版本 —— 如果那个 commit 已被 force push 覆盖或 tag 删除，回滚就会失败。
- 先确认 lock 文件是否干净：运行
git status composer.lock，如果显示modified，说明它不是你要的历史状态 - 恢复目标版本的 lock：用
git checkout <commit-hash> -- composer.lock</commit-hash>（比如回退到上周部署前的 commit） - 删掉
vendor/：rm -rf vendor（Windows 用户请手动删除） - 再跑
composer install—— 此时它才严格按 lock 里的dist/url和reference拉取，不会查私有源的最新 tag
私有源 URL 改了或认证失效，回滚直接报 401/404
私有包回滚失败最常见的原因是：URL 变了、token 过期、Git 仓库权限收紧，或者私有 Packagist（如 Satis / Private Packagist）本身没保留旧版本的 dist 包。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查当前私有源是否还能访问旧版本：手动 curl
https://your-private-repo.com/p2/your/package.json，看响应里有没有你要的"2.3.1"版本条目 - 确认认证方式：如果用了
github-oauth或http-basic，检查auth.json是否在项目根目录（优先级高于全局），且 token 未过期 - 若私有源是 Git 类型（
"type": "vcs"），确保对应分支/commit 仍可被git clone—— 比如"reference": "a1b2c3d"在 lock 里，但该 commit 已被git push --force清掉，就必然失败 - 临时绕过认证验证：加
-vvv参数跑composer install，看日志里实际请求的 URL 和返回的 HTTP 状态码
只想降级一个私有包，别碰其他依赖
不要手动改 composer.json 里私有包的版本号再跑 composer update —— 它会触发整套依赖解析，可能把 monolog 或 symfony/http-foundation 也带上升级，破坏一致性。
- 查可用版本：运行
composer show -a your/private-package，确认目标版本（如v1.8.0）在私有源中真实存在且未标记为abandoned - 精准降级：执行
composer require your/private-package:^1.8 --with-all-dependencies，它会只更新该包及其子依赖的 lock 条目，不动其他包 - 如果报
Your requirements could not be resolved，用composer why-not your/private-package:1.8.0查哪个包在锁死更高版本（常见于your/common-lib的require里写了"^2.0"） - 降级后务必
git add composer.lock && git commit -m "downgrade your/private-package to v1.8.0"，否则下次install还是装新包
私有源同步延迟或缓存污染，导致回滚卡住
很多团队用自建 Satis 或 Toran Proxy，但这些服务默认不保留旧 dist 包，或元数据缓存没及时刷新 —— 表现为 lock 里明明写了 "2.1.0"，composer install 却报 Could not find package your/private-package at version 2.1.0。
- 登录私有源后台，确认
your/private-package的2.1.0tag 是否还在 packages 列表里；若已下线，需手动 re-publish 或从备份恢复 dist tarball - 清私有源缓存：Satis 用户删
web/packages.json并重跑php bin/satis build ...；Private Packagist 用户点 “Refresh metadata” - 本地强制清 Composer 缓存：
composer clear-cache，否则它可能还拿着旧的 repo index - 终极验证：临时把私有源 URL 改成
https://your-private-repo.com/p2/your/private-package/2.1.0.json直接浏览器访问，看能否拿到完整元数据
私有包回滚最脆弱的环节不在命令怎么写，而在私有源本身是否真正“存档”了旧版本 —— 如果你们的 CI 每次发布都删掉旧 tag、Satis 构建时不加 --skip-errors、或者用的是无状态的临时镜像，那 lock 文件再准也没用。回滚前先确认私有源的“时间机器”能力，比敲十遍 composer install 更重要。
