一句话定义：ACID 是数据库事务（transaction）的四条保证：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。它回答的是同一个问题：如果一组操作必须“当作一件事”来看待，数据库怎么保证不出错。
用一个转账例子说明。A 给 B 转 100 元，要拆成“A 扣 100”和“B 加 100”两步。
原子性说的是这两步绑成一个整体，要么都成功，要么都当没发生。中途报错、程序崩溃，数据库会把做了一半的改动撤销（回滚），不会留下来。
持久性说的是，一旦你提交（commit），这笔钱就确定生效了，之后断电、重启、进程被杀，数据都还在。数据库靠先把变更写进日志再慢慢写入磁盘来实现。
一致性最容易被误解：它由应用代码和数据库约束共同保证，数据库自身并不保证业务规则。比如“转账前后总金额不变”“余额不能为负”，这是你写在代码和约束里的规则，ACID 只是不让你在中间状态上把它破坏掉。
隔离性说的是多个事务同时跑时，彼此能看到对方多少中间状态。它没有绝对的对错，只有“你愿意付出多少并发性能，换取数据准确”：隔离越严，越不容易看到脏数据，但锁得越死、并发越低。常见的问题有三种：读到别人还没提交的脏数据（脏读）；同一个事务里读两次同一行，结果不一样（不可重复读）；同一个事务里查两次，行数变了（幻读）。
| 字母 | 保证什么 | 主要靠谁 | 日常踩坑频率 |
|---|---|---|---|
| A 原子性 | 一组操作，全成功或全回滚 | 数据库 | 低，报错自动回滚 |
| C 一致性 | 数据满足约束和业务规则 | 你的代码 + 数据库约束 | 中，多半是代码写漏了 |
| I 隔离性 | 并发事务之间互不干扰的程度 | 数据库 + 你选的隔离级别 | 高，超卖、重复插入多出于此 |
| D 持久性 | 提交了就不会丢 | 数据库 | 低，但出问题最致命 |
和相邻概念的区别：ACID 是单库事务的经典模型，BASE（基本可用、软状态、最终一致）是分布式场景下的折中取舍；CAP 讲的是网络分区时一致性与可用性怎么选。三者不在一个层面上，别混着背。另外注意“一致性”在 ACID 里指数据不违反约束，在 CAP 和分布式讨论里多指多副本之间是否一致，是同名不同义的两个词。
对从业者的实际意义：四个词里，真正影响你写代码的是隔离性。原子性和持久性基本由数据库兜底，你只要记住“事务别写太长、别在里面调外部接口”就够了；一致性靠约束和代码；而隔离性是你每天都要面对的：两个请求同时读到库存为 1，然后都去减，就超卖了。解法不是把隔离级别调到最高（并发会很难看），而是在关键路径上用对工具：行锁、乐观锁版本号、唯一索引兜底。不同数据库的默认隔离级别并不相同，具体以官方文档为准，但代码绝不能依赖“默认就是安全的”。
一句话记住：如果你只想要一个稳妥的写法，事务负责“不出半截子事”，约束和幂等负责“不出重复的事”。