执行历史

并发对象历史像一份 API 收据：谁调用了什么、何时返回、得到什么结果。分布式执行像系统内部录像：进程走了哪些步骤、消息何时发送接收、哪些节点故障。两者都可能被口语称作 “history”，但保留的信息和可证明性质不同。

线性一致性只需要接口历史来寻找线性化见证；消息因果、故障检测与公平进展则必须观察完整执行。先选对象，再写性质，可以避免把内部调度边误当成客户端可见顺序。

验证并发队列时，若性质只谈 enqueue、dequeue 的调用、返回值和实时先后，应使用并发对象历史。分析复制协议中的因果一致性时，发送、接收、程序顺序和版本可见关系不能丢失，应使用分布式执行。

检查线性一致性公理库线性一致性Linearizability每次操作可放置在调用与返回之间的单点，使历史等价于满足实时顺序的顺序规范。时，可先从内部执行投影出接口历史，再寻找满足顺序规格的线性化。验证时序性质时，则把完整执行解释为轨迹或路径公理库轨迹与路径语义Trace semantics · Path semantics · Execution traces以状态路径和可观察动作轨迹描述有限、无限与最大行为，并说明投影和隐藏会遗忘什么。。每一步都应说明保留了哪些事件和顺序。

运行日志不自动等于任一形式对象。墙钟会漂移，采集器可能漏事件，写盘顺序也未必表示因果顺序，接口日志还可能缺少调用—返回配对。用日志验证前必须给出正规化、缺失事件与并列时间戳的处理规则。

新条目若讨论对象一致性，应直接引用并发对象历史；若讨论消息、故障、调度或无限进展，应直接引用分布式执行。只有正文需要解释两种含义的差别时，才链接本页。

将两种对象强行合并成包含大量可选字段的统一 History 类型，不会消除区别；每个定理仍需重新声明自己量化的事件、可见性与顺序。显式分流反而使关系图和学习路径更精确。