CAP 定理怎么解释？为什么不能简单说三选二？
面试怎么回答
CAP 要放在网络分区前提下解释：跨节点无法通信时，不能同时保证线性一致性和所有非故障节点请求都完成。C 不是普通口径一致，A 也不是返回错误就算成功。我会按业务操作明确哪些请求等待或拒绝，哪些可以返回旧值或独立写入，并说明分区恢复后的冲突处理与对账，避免简单给整个系统贴三选二标签。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
两地节点之间断网，一侧刚确认订单状态已更新，另一侧马上收到查询。它无法问到最新状态，此时应该返回旧值，还是暂时无法完成请求？从这个场景出发，CAP 才有具体含义。
发生网络分区时，系统无法同时保证线性一致性与所有非故障节点请求都能完成；工程上需要按操作定义等待、拒绝、降级和冲突修复。
CAP 的一致性不是所有同名概念
CAP 讨论的一致性通常指线性一致性：操作看起来像按一个全局顺序即时生效，并尊重已经完成操作的真实先后关系。某次写入已经成功返回，之后的读取不能任意看见更旧状态。
这与数据库 ACID 中约束不变量的一致性、最终一致性、数仓两张报表口径一致并不是同一层含义。面试时先把定义限定清楚，才不会用“我们每天能对上账”来证明一个在线服务满足 CAP 中的强一致要求。
可用性也不能直接等同业务 SLA
定理里的可用性要求到达非故障节点的请求最终能够完成，不等同于某个产品宣传的成功率，也不能靠立即返回错误就宣称同时保住了所有保证。
工程 SLA 会增加延迟、错误预算和可接受降级内容，这些比定理定义更具体。讨论选型时应明确：旧值能不能返回、写入可不可以排队、多久可以超时、哪些结果对业务有效，而不是只给系统贴一个两个字母的标签。
网络分区时，另一侧无法确定最新事实
假设节点甲确认写入完成，节点乙因为断网无法收到变化。随后乙收到读取：若直接返回旧值，就不能保证线性一致性；若一定要等甲确认，在分区持续时就无法保证这个请求完成。
这个两难来自通信条件。对跨节点系统，不能简单声明不选择分区容错，就让现实网络分区消失。没有发生分区时，可以同时提供良好的读写一致性和可用服务，只是仍需付出协调、延迟与资源成本。
一个典型场景：所有读请求统一降级
比如业务为了保证库存扣减正确，网络异常时让无法确认一致性的写入失败，但把商品描述查询也一并停掉。初步方案用“系统选 CP”解释所有行为，实际把不同数据的容忍度混在了一起。
库存约束可能需要拒绝不安全写入，商品说明则可以在明确版本和时效条件下返回缓存。原设计只按组件贴标签，没有按操作区分契约。改进应分别说明每类请求的保证和降级语义，不能把返回缓存仍描述成原来的强一致读取。
接受分区期间写入，就要设计如何收敛
如果业务允许两侧独立接收修改，网络恢复后必须处理冲突：保留哪一个版本、是否合并、是否需要人工判断，都取决于数据语义。不能把最终一致理解成系统会自动得出业务正确答案。
只按本地时间最后写入获胜，会受时钟误差和业务先后关系影响；简单覆盖也可能丢失有效更新。对账、冲突记录、幂等补偿和可解释的合并规则都应进入方案。CAP 给出限制，真正的工程回答要把限制落实到具体读写行为。