Composer 不参与代码交付层（如分支策略、PR 模板），仅在质量门禁层封装检查命令、在环境一致性层锁定依赖与 PHP 平台契约，其核心价值是保障环境就绪与契约一致，而非驱动协作流程。

Composer 本身不制定工作流，也不管理 Git 分支、任务分配或文档协作——它只是 PHP 的依赖管理工具。如果你在团队扩张中试图用 composer 命令“标准化开发流程”，大概率会踩进配置错位、职责混淆、自动化失效的坑。

---

为什么不能靠 composer 沉淀工作流？

• composer.json 只定义依赖、自动加载、脚本别名（如 "scripts": {"test": "phpunit"}），它不描述“谁在何时做什么”；
• 工作流的核心是人与人的协作节奏（例如：需求评审 → 开发 → PR → CI 检查 → 合并 → 发布），而 composer 无权触发、阻断或记录这些节点；
• 把流程逻辑硬塞进 composer scripts（比如写个 "deploy:staging"）会导致：
  • 脚本越来越长，难以维护；
  • 权限失控（本地执行 composer run deploy:staging 可能直接推到预发环境）；
  • 与 CI/CD 工具（如 GitHub Actions、GitLab CI）重复甚至冲突。

---

那 composer 在工作流里该承担什么角色？

它只做一件明确的事：统一环境就绪动作。具体可落地为：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• composer install 确保所有开发者拉下相同版本的依赖（配合 composer.lock 提交）；
• composer dump-autoload --optimize 用于构建阶段加速自动加载（但仅在生产部署时启用）；
• 自定义脚本仅封装纯本地、无副作用、可重复的操作，例如：

  "scripts": {
  "dev:start": "php -S localhost:8000 -t public/",
  "cs:fix": "php-cs-fixer fix --dry-run",
  "test:unit": "phpunit --testsuite=unit"
  }

• 所有涉及外部系统（如 Git 推送、Jira 更新、Slack 通知）的动作，必须交给专用工具（Git Hooks、CI 配置、自研 CLI 工具）处理，不要塞进 composer.json。

---

团队扩张时真正该标准化的三个层

层级	关键载体	composer 是否参与
代码交付层	Git 分支策略（main / develop / feature/*）、PR 模板、合并规则	否 —— 由 Git 和 CI 控制
质量门禁层	PHPUnit / Psalm / PHPStan 集成、CS 自动修复、覆盖率阈值检查	是 —— 通过 composer scripts 封装命令，但执行由 CI 触发
环境一致性层	composer.lock 提交、PHP 版本约束（"config": {"platform": {"php": "8.2.10"}}）、扩展要求（"ext-mbstring": "*"）	是 —— 这是它最不可替代的作用

---

composer 的价值不在“驱动流程”，而在“锁定契约”。团队越大，越要警惕把协作逻辑误塞进依赖配置文件——那不是沉淀最佳实践，是把工作流藏进了一个别人不敢轻易改的 JSON 里。