GitHub Actions 默认支持并行执行，无需配置；需控制并行时才用 concurrency，可作用于工作流或作业级，按分支、环境等动态分组，并支持 cancel-in-progress 自动取消进行中的同组任务。
GitHub Actions 默认就支持并行执行工作流和作业，不需要额外配置就能同时运行多个工作流或同一工作流的多个作业。
如果你希望允许并行（即保持默认行为），什么也不用做——只要不设置 concurrency，系统就会自动并发运行。
但更常见的情况是：你想控制并行，比如避免多个部署同时冲向生产环境，或防止资源争抢。这时才需要主动配置。
明确哪些场景需要控制并行
- 多个 PR 同时触发测试，想让它们各自独立、并行跑（默认就是如此）
- 多次 push 到 main 分支，不想让后续构建排队等待前一个完成（默认也是并行）
- 部署到 staging 或 production 环境时，必须串行，避免覆盖或冲突
- 使用自托管运行器且数量有限，需限制同时占用数
用 concurrency 控制并行粒度
concurrency 可以作用于整个工作流，也可以细化到单个作业，支持按分支、环境、事件类型等动态分组：
# 工作流级别：同一 concurrency 组内只允许一个实例运行
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
-
group决定哪些运行属于“同一组”，同组不会并行 -
cancel-in-progress: true表示新触发时，自动取消正在运行的同组任务
常见写法示例：
-
按环境串行部署：
concurrency: group: deploy-${{ github.head_ref || github.ref_name }} cancel-in-progress: true -
仅对 production 环境限制并发，其他照常并行：
concurrency: ${{ (github.event_name == 'push' && github.ref == 'refs/heads/main') && 'production-deploy' || '' }} -
作业级别单独控制（比如只让部署作业串行，测试作业仍并行）：
jobs: test: runs-on: ubuntu-latest steps: [...] deploy: runs-on: ubuntu-latest concurrency: group: deploy-prod cancel-in-progress: true steps: [...]
注意事项
-
concurrency不影响不同工作流之间的并行性，只约束同一工作流或指定作业组 -
group值支持表达式，可结合github.*上下文动态生成，比如${{ github.repository }}-staging -
cancel-in-progress对 workflow_dispatch 或手动触发特别有用，能及时中断旧的调试部署 - 如果完全禁用并行（比如测试必须单例运行），可以把 group 固定为一个常量，如
concurrency: single-test-run
不复杂但容易忽略
