编写术语词汇定义

术语：验收标准（Acceptance Criteria）

定义：

• 对某个需求、用户故事、功能或交付件被视为“完成并可被接受”所必须满足的一组明确、可验证、可度量的条件。验收标准以用户可观察的行为或可测量的结果为依据，用于判定交付内容是否满足业务与质量要求。

目的：

• 统一干系人对需求边界与完成定义的理解
• 为测试设计与用户验收提供判定依据
• 降低歧义，减少返工与范围蔓延

关键特性：

• 可测试：每条标准应能通过测试产生明确的通过/不通过结果
• 明确无歧义：表述清晰、具体，避免主观词汇（如“快速”“易用”）
• 可度量：包含可量化阈值（如时延、精度、数量、范围）
• 与实现无关：描述行为与结果，而非技术实现方式
• 可追溯：可与上位需求或业务目标建立对应关系

常用表达形式：

• 条目式清单（布尔判定）
• 场景式描述（例如：Given-When-Then 行为场景）

适用范围与阶段：

• 需求分析与拆分、迭代计划、开发与测试、用户验收（UAT）全流程

与相关术语的区分：

• 完成的定义（Definition of Done, DoD）：团队级通用质量门槛（如编码规范、代码评审、覆盖率下限）；验收标准：针对单条需求/用户故事的特定完成判定条件
• 验收测试（Acceptance Tests）：基于验收标准编写的具体测试用例与步骤

简要示例：

• 当用户提交有效邮箱并点击“重置密码”时，系统在1分钟内向该邮箱发送包含重置链接的邮件；链接有效期为24小时且仅可使用一次；失败请求返回明确错误信息且不暴露账户存在性。

术语：幂等性（Idempotency）

定义： 指某操作在相同输入与相同前置条件下被执行一次或多次，其对系统可观察状态的最终效果等同于执行一次。响应内容或元数据可因时间、缓存等因素不同，但资源的意图状态与副作用的累计结果不发生额外变化。

适用条件与范围：

• 相同输入、相同目标资源与相同前置条件（如资源版本）。
• 不受其他并发写入的干扰，或通过条件更新将该约束显式化。
• 关注的是对系统状态的效果一致性，而非字节级响应一致性。

与相关概念的区别：

• 安全性（Safe）：不改变服务器状态（如 GET）。幂等性允许改变状态，但重复执行不产生新的变化（如 PUT、DELETE）。
• 可交换性（Commutativity）：与执行顺序相关，非幂等性的必要条件。

典型标准与场景：

• HTTP：GET、HEAD、PUT、DELETE、OPTIONS、TRACE 被定义为幂等；POST、PATCH 通常不幂等（依据 HTTP 语义 RFC 9110）。
• 分布式/消息系统：用于抵御网络重试与重复投递（“至少一次投递”）导致的重复执行。

实现要点（常用机制）：

• 幂等键（Idempotency-Key）：客户端为每次“意图”生成唯一键，服务端按键去重并返回首次结果；需定义键格式、作用范围与过期策略（TTL）。
• 条件写入与版本控制：If-Match/ETag、版本号、Compare-and-Swap（CAS）、数据库唯一约束、UPSERT，确保“只生效一次”或“覆盖写入”。
• 外部副作用去重：对出站操作（如扣款、发信）使用事件/消息唯一 ID、去重表或事务外发箱（Outbox）模式，避免重复触发。

示例：

• 幂等：PUT /users/42 更新同一表示；DELETE /orders/1 重复删除；SQL：UPDATE users SET status='active' WHERE id=1；INSERT … ON CONFLICT DO UPDATE/DO NOTHING。
• 非幂等：POST /orders 创建订单；PATCH /cart 增加数量；SQL：UPDATE balance = balance + 10。

文档化建议：

• 明确标注哪些操作幂等、幂等键的使用规则与作用域、重复请求的期望响应语义（例如返回首次结果或幂等冲突指示）。
• 说明并发写入策略与失败重试策略，尤其是涉及计费、通知等副作用的处理与去重要求。