📄 一句话概括
技术威胁＝软件与系统层面的故障：程序 Bug、内存损坏、进程崩溃、系统死机——对策是让错误被抓住、被记录、可重来。
📝 本节和前面几节的关系
7-1 的灾祸看得见，本节的故障藏在软件里：一切看起来好好的，数据却错了、程序却死了。它的两个出口正是本章后半的展开——错误要记下来（7-4 错误日志）→ 分析类型（7-5）→ 揪出慢的（7-6）。
一、技术威胁清单
| 威胁 | 后果 | 对策 |
|---|---|---|
| 软件 Bug | 数据算错、意外崩溃 | 测试、版本管理、及时修补（6-9） |
| 内存/磁盘损坏（软性） | 数据悄悄变坏（静默损坏） | 校验和、定期校验 |
| 进程崩溃 | 服务中断 | 自动重启、看门狗 |
| 操作系统死机 | 全部服务停摆 | 隔离部署、快速恢复预案 |
| 并发冲突 | 数据互相覆盖 | 事务与锁（4-14/4-17） |
二、对策三板斧
- 防：测试覆盖、灰度发布——让 Bug 活不到生产环境
- 抓：日志与监控（6-5）——错误一发生就有记录，不靠用户投诉才发现
- 回：事务回滚（4-16）＋备份还原（6-6/6-7）——错到哪一步都能退回
三、动手 Demo：制造一次「技术故障」并观察恢复
-- SQLite 在线运行器里模拟「进程崩溃后的恢复」
-- ① 正常写入并提交
CREATE TABLE t (id INTEGER PRIMARY KEY, v TEXT);
INSERT INTO t VALUES (1, '好数据');
-- ② 假设此刻进程崩溃（想象关掉页面再重开）
-- ③ 重开后：已提交的数据完好 —— 这就是事务（4-14）的持久性
SELECT * FROM t; -- '好数据' 还在
-- ④ 未提交的半截写入呢？—— 重启后被自动回滚，库里不留垃圾
【准备块】在线 SQLite 运行器即可；核心体会＝「崩溃不可怕，可怕的是崩溃后库里留下半成品」。
四、30 秒实验
手机 App 闪退后重开，进度还在吗？——游戏存档在（提交过）、未保存的输入丢了（没提交）。这就是「事务持久性」的日常版。
五、常见误区
- 「代码写得好就不会有技术故障」：内存翻转、驱动 Bug、依赖库漏洞都不在你的代码里——防不住的，靠抓和回
- 「崩溃=数据全丢」：有事务的数据库，崩溃只丢「未提交」的部分，已提交的完好
- 「错误日志是出事才看」：日常巡检日志（6-5）才能在小事变大前拦住
自测三问
1. 技术威胁与物理威胁的分界？（物理＝硬件与环境的实体损坏；技术＝软件系统层面的故障） 2. 对策三板斧？（防——测试；抓——日志监控；回——回滚与还原） 3. 进程崩溃后，未提交的写入去哪了？（被事务机制自动回滚，库里不留半成品）- ☐ 下一节（7-3 人的威胁-对系统产生恶劣影响的问题3-人的威胁示例与对策）
相关笔记
- 物理威胁-对系统产生恶劣影响的问题1-物理威胁示例与对策 —— 上一类：看得见的灾祸
- 事务-集中执行无法分割的处理 —— 崩溃后「已提交完好、未提交回滚」的机制出处
- 操作历史、日志、资源-监控数据库 —— 三板斧中「抓」的基础设施
- 🗄️ 数据库基础 · 索引 —— 全课路线图