Composer 不支持敏捷开发模式切换，其依赖管理需通过分支策略、lock 文件提交、--no-dev 部署、私有包 dist 配置及缓存优化来保障 CI 稳定性。
Composer 本身不支持“敏捷开发模式切换”，它只是 PHP 的依赖管理工具；所谓“敏捷中管理依赖”，本质是围绕快速迭代、分支协作、环境隔离做流程设计，不是靠某个命令开关实现的。
composer.json 的版本约束怎么写才不影响每日构建
松散版本（如 ^2.0）在 composer update 时可能拉入不兼容的次版本，导致 CI 构建失败。团队高频迭代时，应优先用锁定策略而非盲目放宽约束：
- 主干（main/stable）分支：用固定版本或
~2.4.0这类保守范围，明确控制变更边界 - 功能分支（feature/*）：可临时允许
^2.0，但合并前必须运行composer update --dry-run检查实际升级项 - 永远提交
composer.lock—— 它才是每次构建真实还原依赖的依据，不是可选文件
多环境依赖差异（dev vs prod）如何避免上线漏装包
require-dev 里的包（如 phpunit/phpunit）默认不会被生产环境安装，但有人会误用 composer install 不带参数，导致本地能跑、线上报 Class not found。关键动作是：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- CI/CD 流水线部署时，强制使用
composer install --no-dev --optimize-autoloader - 本地开发需启用某些 dev 包时，用
composer install --with-all-dependencies显式包含，而非删掉--no-dev - 检查
autoload-dev是否意外把测试辅助类注册进生产 autoloader —— 这会导致 class 冲突或性能损耗
私有包频繁更新时，如何让 composer update 不卡住 CI
私有 Git 仓库（如 GitHub/GitLab 私有库）若没配置 dist 镜像或缓存，每次 composer update 都走源码克隆，极易超时。解决路径很直接：
- 在
composer.json的repositories中为私有包指定type: "package"+dist下载地址，跳过 git clone - CI 环境启用 Composer 缓存目录（如 GitHub Actions 的
actions/cache指向~/.composer/cache） - 避免在
post-update-cmd中执行耗时脚本（如生成文档、打包前端）—— 这会让composer update表面成功、实则阻塞后续步骤
最常被忽略的一点：composer.lock 文件的变更必须和代码逻辑变更保持原子性。一次功能提交里如果只改了 composer.json 却忘了提交 composer.lock，或者反过来只提交了 lock 文件而没说明依赖为何升级，协作成本会指数级上升。
