事务保障数据库操作原子性而非本地数据读写原子性：1.SQLite支持ACID事务；2.内存变量需手动快照+锁模拟；3.文件操作用临时文件+原子重命名；4.事务不解决非DB操作或设计缺陷。
事务（transaction）本身不直接保证“本地数据读写的原子性”，它保障的是**数据库操作的原子性**——即一组 SQL 语句要么全部成功提交，要么全部回滚，不存在中间状态。所谓“本地数据”若指内存变量、文件、JSON 文件、SQLite 本地数据库等，需分场景理解：
1. 使用 SQLite 等嵌入式数据库时，事务天然可用
SQLite 是进程内数据库，支持 ACID，开启事务即可确保多条写操作的原子性：
- 用 BEGIN TRANSACTION 或 BEGIN IMMEDIATE 显式开启事务
- 执行多条 INSERT/UPDATE/DELETE
- 成功则 COMMIT，失败则 ROLLBACK
例如 Python 中：
conn.execute("BEGIN IMMEDIATE")
try:
conn.execute("UPDATE accounts SET balance = balance - 100 WHERE id = 1")
conn.execute("UPDATE accounts SET balance = balance + 100 WHERE id = 2")
conn.execute("INSERT INTO transfers VALUES (?, ?)", (1, 2))
conn.execute("COMMIT")
except:
conn.execute("ROLLBACK")
raise2. 纯内存数据（如 dict/list）无法靠数据库事务保护
内存结构没有持久化和回滚能力。要模拟原子性，需手动实现状态快照或两阶段提交逻辑：
- 修改前深拷贝原状态（适用于小数据量）
- 所有变更在副本上进行，验证通过后再整体替换原对象
- 配合锁（如 threading.Lock）防止并发读写冲突
注意：这不是真正的事务，只是应用层规避策略，崩溃时仍会丢失。
3. 操作本地文件（如 JSON/CSV）需自行封装事务语义
文件系统不提供事务，但可通过“临时文件 + 原子重命名”逼近效果：
- 读取原始文件 → 解析为内存数据
- 在内存中完成全部变更 → 序列化到临时文件（如
data.json.tmp） - 调用 os.replace()（Python）或 mv -T（Linux）原子替换原文件
- 若中途失败，原始文件保持不变
该方式只保障单文件写入的原子性，跨多个文件仍需额外协调（如写日志记录操作步骤，崩溃后重放或清理）。
4. 不要误用“事务”掩盖设计缺陷
事务不能解决以下问题：
- 读操作本身不加锁，默认可能读到旧值（需配合隔离级别，如 READ COMMITTED）
- 非数据库操作（发 HTTP 请求、写日志、改硬件状态）无法纳入事务范围
- 长时间运行的操作容易导致锁竞争或超时，应拆分为幂等小事务
真正需要强一致性的本地场景，优先选 SQLite；轻量且无并发，可接受最终一致，用文件+临时写法；高频并发内存操作，考虑使用支持事务的嵌入式键值库（如 BadgerDB、BoltDB）。
