并发控制丢弃排队中的过时验收任务

持续集成鼓励开发者一天内频繁提交代码，[[部署流水线三阶段的时间预算]]里提交阶段要求几分钟内跑完，但验收阶段要跑性能、安全这类慢测试，天然比提交阶段慢得多。如果每次提交阶段完成都触发一次验收阶段，短时间内提交阶段跑完好几轮，验收阶段的任务就会排队积压。这里的关键判断是：排队中间的那些候选版本没有必要逐个验证，因为只要最新的候选版本通过验收，之前排队的旧版本就已经过时、不再有被单独部署的价值。GitHub Actions 用一个 concurrency 分组来解决——同一分组内只允许一个验收任务在跑，新任务触发时会自动取消还在排队等待的旧任务，只保留正在执行和最新触发的这一个。发散：这是”只有最新状态有意义，中间状态可以丢弃”这种思路在 CI/CD 排队场景的具体实现，本质和很多”合并連續事件只处理最后一次”的节流（debounce）逻辑是同一类问题。