一句话：CAP 定理（CAP theorem）说，一个分布式系统在一致性、可用性、分区容忍这三件事里，最多只能同时拿到两件。
先拆词。一致性（Consistency，更准确说是线性一致性）指所有节点在同一时刻看到同一份数据，你刚写入，别人立刻读到。可用性（Availability）指每个请求都能在合理时间内拿到一个非错误的回答——注意是“非错误”，不是“最新”。分区容忍（Partition tolerance）指节点之间的网络断掉、消息丢失或延迟时，系统还能继续运转。
关键在于：网络分区不是“会不会发生”，而是“什么时候发生”。机房之间的光纤会被挖断，云厂商的网络会抖动，Kubernetes 里的 Pod 会失联。所以 P 通常没得选，除非你干脆不承认自己在做分布式。于是真正的取舍发生在分区那一刻：要么拒绝一部分请求、报错保正确（CP），要么照常响应、但数据可能是旧的（AP）。
打个比方：一家连锁奶茶店，各分店各自记着价格表。总部和分店之间的电话线断了。如果坚持“所有分店价格必须一致”，那电话不通时就不能卖货——保 C 弃 A；如果坚持“任何时候都能下单”，那分店只能按手里的旧价卖——保 A 弃 C。而电话线断不断，不是老板说了算，这就是 P。
容易混的几个邻居：
| 概念 | 关注点 | 和 CAP 的关系 |
|---|---|---|
| ACID | 数据库事务的原子性、隔离性等 | 其中的 C 指“约束不被破坏”，和 CAP 的 C 不是一回事 |
| BASE | 基本可用、软状态、最终一致 | 主动选择 AP 之后的一套路子 |
| PACELC | 无分区时还要权衡延迟与一致性 | CAP 的补充：不出故障时也没法全都要 |
所以不必背“三选二”的结论，记住动作顺序更有用：先认下 P，再问自己“分区时，业务更能接受读旧数据，还是更能接受请求失败”。配置中心、分布式锁、账务系统通常选 CP；购物车、点赞数、DNS 通常选 AP。
对从业者，这意味着选型是选“故障时的姿态”，不是选一个更高级的数据库；做架构评审时，把“分区时怎么办”写进文档，比事后救火便宜得多。对普通人，它解释了为什么手机 App 偶尔会弹“网络开小差了，请稍后重试”，也解释了为什么大促时系统宁可短暂拒绝下单，也不愿把同一件商品卖给两个人。具体某个产品的默认策略和参数，各家实现不同，以官方页面为准。