闭合感一条要求任务有明确的开始与结束标志，这是其余各条不覆盖的
别名: 闭合标志 · 任务边界 · 流程完成 · 假闭合
概念解释
闭合（closure）要求任务边界可识别：用户知道请求何时被接受、处理到哪个阶段、何时完成、失败时如何结束、暂停时如何恢复。一致性、反馈或控制可以支持闭合，但不能替代对开始与结束状态的定义——这正是这一条在八条法则里的独特位置：一致性问的是"同一件事有没有被说成两种样子"，反馈问的是"用户能不能看到发生了什么"，控制感问的是"用户能不能干预"，但这三条即使都做到了，也不必然回答"这件事到底结束了没有"这个问题，闭合是唯一专门盯着任务边界本身的一条。
机制
其余七条法则（一致性、反馈、普遍可用性、预防错误、可逆、控制感、记忆负担）描述的都是交互过程内部某个属性该怎么保持，它们成立不需要预设"这是一个有边界的任务"这个概念——一致性可以贯穿整个产品生命周期持续起作用，反馈可以针对任意一次单独动作给出，控制感可以在没有明确起止的持续监控场景里同样成立。闭合是唯一一条把"任务"本身当作一个需要被识别的单元来处理的法则，它多问了前面七条都不问的两件事：这件事从哪一刻算开始（承诺点：用户的哪个动作让系统正式接受了这个请求），以及从哪一刻算结束。开始标志容易被忽略，因为它常常隐藏在一个不起眼的按钮点击里——但如果用户不确定自己的操作是否已经被系统正式受理（比如提交按钮点了但没有任何变化），他会重复点击、怀疑是否失败，这和"不知道有没有做完"是同一类不确定，只是发生在任务的另一端。有了明确的起止两个标志，用户才能把这段交互当作一个可以从注意力里卸载的完整单元，这是前面七条无论做得多好都无法单独提供的。
边界
不是所有任务都适合被强行框成一个"完整闭环"。持续监控类任务、协作编辑、跨越数周的长期项目本质上是持续开放的，起点或许清楚，但没有一个自然的终点；这种情况下正确的做法不是在每次会话结束时都伪造一个"圆满收尾"的终点标志，而是提供里程碑、明确的当前责任人和随时可查的开放状态，诚实地承认它还没有结束。另一个边界在起点一端：如果系统的受理并不是即时的（比如需要排队等待人工审核），过早显示"已受理"这个起点标志同样会造成后续的信任落差——用户会按"已经开始处理"这个假设去规划后续动作，一旦审核队列很长，这个假设本身就是错的。起点标志的可信度要求和终点标志是对称的，不能只在终点这一头讲究诚实。
怎么落地
- 为每个关键任务明确定义开始条件、阶段划分、完成证据、失败状态、取消路径和暂停后的恢复方式，六种出口状态缺一不可；开始条件要单独核实系统是否已真正受理，而不是默认"点了按钮就等于开始"。
- 完成页只在真正拿到完成证据后展示，内容包括结果摘要、时间、受影响对象数、下一步和撤销/继续入口；依赖后台异步确认的场景要等确认信号到达再展示，不要提前展示。
- 跨角色、跨页面的流程使用同一套状态名称，并明确写出不同角色在同一状态下各自能看到什么、能做什么，避免"完成"对甲角色和乙角色意味着不同的事。
- 验证办法：走查中断与返回路径，在用户重新进入一个曾经离开的任务时问他"你现在做到哪一步了、接下来还要做什么"，答不上来或答错，说明当前的闭合信号缺失或出现得太早太模糊。