研究报告 · 约 40,059 字 · 预计推送 5 部分

数据完整性工程：校验和、内容寻址、原子写入、文件锁与崩溃恢复——70 年演进与 2026 选型格局综合报告 未开始

目录

题记与说明

综合说明：本报告由两份分轴研究综合而成——纵轴《数据完整性工程（校验和、内容寻址、原子写入、文件锁与崩溃恢复）——纵轴发展历程》（1948–2026，六阶段）与横轴《数据完整性工程——横向对比报告》（2026-11-04 时间截面，五子领域 × 五维度），原始文件存于 parts/ 子目录。综合时完成了三类工作：①校准两章之间的矛盾与口径差异（共 5 处，逐条记录见文末附录"综合校准记录"，含 BLAKE3 发布年份、SHA-1 碰撞佐证层级、BLAKE3 速度倍数两种口径等）；②合并两章重复叙述的主题（flock/fcntl 语义分歧与三大锁史文献、SQLite WAL 双重叙述、FAST '10 ZFS 论文、BLAKE3 规格、Git SHA-256 现状），正文只详述一次，其余位置交叉引用；③新增"交叉洞察"一节，把纵轴的历史规律与横轴的当下格局结合成判断与建议。全部事实与数字保留原始出处链接；纵轴稿自述其事实经 2026-11-04 网络检索核对一手来源，横轴稿自述基于当日检索，两稿各自标注的"背景知识"处本综合沿用原标注，未新增未经来源的数字。定稿前按独立审读意见完成 8 条修订（引用出处核实、计数、术语定义、口径量纲与落地配方），逐条记录见文末附录二。数据截面：2026-11-04。

TL;DR

数据完整性工程由五个互相咬合的子领域构成：校验和发现损坏、内容寻址让哈希成为身份、原子写入让"写一半"不可见、文件锁让并发写入有序、崩溃恢复让断电后回到一致状态。纵轴 70 年：汉明码（1950）与 CRC（1961）奠基，LFS 与 ARIES（1992）确立日志恢复，2005 年 ZFS 与 Git 同年兑现端到端校验与内容寻址，2010 年 SQLite WAL 把日志带给大众，2015–2018 年连环事故把"fsync→rename→fsync 目录"钉成标准动作，2021–2026 年进入云默认校验、协议标准化与算力换代。横轴第一定律是三种语义分开买：完整性、原子性、持久性由不同机制、不同档位提供，事故根源几乎都是"以为买了 A，实际只买了 B"——rename 不 fsync、WAL 默认 NORMAL、CRC32C 防不了篡改。选型口诀：防随机错用 CRC32C/XXH3，防篡改用 SHA-256/BLAKE3；小文件替换用库封装的原子舞步，结构化状态直接上 SQLite/LMDB，进程互斥优先内核锁。五子领域咬合成体系，不存在单点最优。

一、纵轴：发展脉络（1948–2026）

主线一句话：数据完整性工程不是一项单一技术的编年史，而是五条子技术线在 70 余年间的反复交汇——每一环最初都因一类具体故障而生（真空管翻转、磁盘静默损坏、断电撕裂、并发覆写、哈希攻破），每一次范式切换都由"旧防线被新故障打穿"触发，而贯穿全程的胜负手是 1984 年 Saltzer 等人提出的端到端论证：把完整性校验提到端点，而不是信任中间任何一层（End-To-End Arguments in System Design, MIT 原文 PDF｜ACM DL）。

阶段一（1948–1979）：数学奠基——从汉明码到 CRC 再到哈希树

驱动因素：真空管与磁芯存储的错误率让"算得对"本身成为工程问题；纠错先长在硬件层，再逐层向上渗透。

阶段二（1970s–1988）：事务恢复成为学科、磁盘学会自愈、文件锁诞生

驱动因素：数据库把崩溃一致性列为硬需求；"更便宜但更会坏"的磁盘经济学；Unix 多用户并发催生锁机制。

阶段三（1990–2004）：日志化文件系统、密码学哈希与增量同步

驱动因素：磁盘寻道与写性能的矛盾（→日志化）、互联网带宽稀缺（→增量传输与去重）、哈希算力普及（→内容身份）。

阶段四（2005–2013）：端到端完整性落地、内容寻址登堂入室

理论支柱早已就位（1984 年端到端论证），2005 年起在存储与应用两侧同时兑现：

驱动因素：磁盘容量增速远超带宽（校验与去重必须内建）、BitKeeper 事件、数据中心规模、1984 年端到端论证的工程兑现。

阶段五（2014–2020）：事故驱动，"崩溃一致性"成为显学

驱动因素：SSD/FTL 带来新故障面、学术工作（UW-Madison 崩溃一致性系列等）与工业事故互相指认、密码学哈希进入"退役周期"。

阶段六（2021–2026）：云默认校验、协议标准化与算力换代

驱动因素：云厂商把"默认校验"当作差异化能力；供应链攻击推高可验证性需求；硬件 CRC32C 指令与并行哈希让校验成本趋近于零；旧算法与旧语义进入集中退役期。

纵轴小结：贯穿 70 年的三条主线

  1. 故障模型下移，防御上移——端到端论证的反复胜出。从磁芯、磁盘到 DMA、FTL、固件，每一层都可能静默出错；单点校验（RAID、链路校验和）反复被"漏网"故障打穿，最终答案总是把校验提到端点：ZFS 的父块指针校验和（2005）、Git 的对象哈希（2005）、S3 的默认 CRC32（2022 前后）是同一论证在三个十年的重复兑现。
  2. "先日志、后改名、再锁"模式固化。LFS 与 ARIES（1992）确立 WAL 与三阶段恢复；ext3 与 SQLite WAL（2010）把日志带给大众；2009 年 O_PONIES 之争与 2018 年 fsyncgate 把"fsync 文件 → rename → fsync 目录"钉成跨平台标准动作；Git 的 lockfile 与 SQLite 的五态锁——即其回滚日志模式的文件锁状态机，按 UNLOCKED→SHARED→RESERVED→PENDING→EXCLUSIVE 五个状态演进（SQLite File Locking 文档）——则是"建议锁"哲学的样板。日志与写时复制两族（ext3/XFS 对 ZFS/Btrfs）在 2025 年的 OpenZFS 2.3 与 PG 18 io_uring 中依然并行演化。
  3. 哈希从检错到身份。CRC（1961）回答"传输出错没有"；MD5/SHA-1（1991–1995）回答"内容可信吗"，并在 2004（MD5 碰撞）与 2017（SHAttered）两次退位；SHA-2/SHA-3/BLAKE3 时代，哈希成为地址（Git、Nix、IPFS、OCI 镜像摘要）与账本（证书透明度、Sigstore）。内容寻址把完整性从"附加校验"升级为"身份即证明"，这是 70 年里最大的一次范式迁移。

二、横轴：横向对比（2026-11-04 截面）

2.1 对比框架：三种语义必须分开买

"数据完整性工程"不是单一技术，而是五个互相咬合的子领域，每个子领域内部都存在多条竞争路线：

子领域核心问题主要竞争路线
校验和怎么发现数据坏了？CRC 系列 / xxHash / SHA-2 / BLAKE3 / 文件系统块级校验
内容寻址怎么用"内容本身"当身份？Git 对象库 / IPFS CID / 备份仓库（restic、Borg）/ 构建缓存 CAS（Bazel、Nix）
原子写入怎么保证读者只见完整的旧文件或完整的新文件？temp+fsync+rename 手工舞步 / 语言库 / Windows 原语 / 内核 RWF_ATOMIC / 直接换嵌入式数据库
文件锁怎么防止两个进程同时改一份数据？flock / fcntl 记录锁 / O_EXCL 锁文件约定 / Windows LockFileEx / 跨平台库
崩溃恢复断电/进程崩溃之后怎么把数据救回来？rollback journal / WAL / Copy-on-Write B 树 / AOF 追加日志 / 文件系统日志

进入逐项对比前，先立一个贯穿全篇的框架——三种语义必须分开买：

工程事故最常见的形态不是"没做数据完整性"，而是以为买了 A，实际只买了 B。下文每个子领域都会回到这条线；纵轴的事故史（O_PONIES、fsyncgate、Files are hard）正是它的历史注脚。

2.2 总览矩阵（五子领域 × 代表方案 × 五维度）

子领域代表方案能力成本生态成熟度最佳适用
校验和CRC32C防随机错，不防篡改硬件加速约 10–30 GB/s极广（网络/存储）数十年传输帧、块设备
校验和xxHash (XXH3)防随机错，非加密AVX2 约 59 GB/s，AVX-512 可超 130 GB/s广（C/Rust/Go/Java）高（2012 起，XXH3 为 2019+）内存级去重、缓存键
校验和SHA-256抗碰撞、防篡改数百 MB/s极广极高签名、证书、内容寻址
校验和BLAKE3抗碰撞 + 并行流式单核约 2.4 GB/s，多核 AVX-512 约 10+ GB/s增长中中高（2020-01-09 发布）大文件快速完整性校验
内容寻址Git 对象库hash=对象 ID，不可变全量对象库有 GC 成本开发者全员极高源码版本管理
内容寻址IPFS CID自描述多层标识符（multihash）CID 结构有开销Web3/分发高去中心化分发、跨算法演进
内容寻址restic / BorgCDC 分块 + 认证加密去重与加密开销备份圈主流高加密去重备份
原子写入temp+fsync+rename原子替换（POSIX）需正确处理 4 步舞 + 目录 fsync各语言均有库极高配置/状态文件更新
原子写入Linux RWF_ATOMIC块层"不断裂写"（硬件保证）需 NVMe/SCSI 硬件支持内核 6.11+，ext4/XFS新兴（2024 起）数据库大页写入
原子写入SQLite / LMDB完整 ACID/快照换抽象的复杂度极广极高结构化状态存储
文件锁flock内核 advisory 锁，进程死自动释放低Unix 系数十年单机多进程互斥
文件锁fcntl/lockf进程级字节范围锁低，但"关任一 fd 即放锁"的坑POSIX 全平台数十年数据库/字节级锁
文件锁proper-lockfile 等锁文件 + mtime 陈旧检测需心跳/超时机制Node 生态高NFS/跨平台场景
崩溃恢复SQLite WAL原子提交 + 并发读WAL 模式默认不防断电极广极高嵌入式事务存储
崩溃恢复LMDB COW B+树结构性免恢复（无需重放）写放大广（OpenLDAP 原生孵化；Postfix、PowerDNS、Monero 等采用）高读多写少的 KV
崩溃恢复Redis AOF追加日志 + 三档 fsynceverysec 约 1 秒丢失窗口极广极高缓存/弱持久 KV

2.3 子领域一：校验和——"发现数据坏了"的六条路线

方案类型速度（单线程量级）对抗强度生态与成熟度适用场景
CRC32 / CRC32C循环冗余校验硬件加速（SSE4.2/ARMv8 CRC 指令）约 10–30+ GB/s无抗碰撞性，可被轻易伪造网络协议、文件系统默认值，数十年防传输/存储随机错误
xxHash（XXH3/XXH128）非加密快速哈希AVX2 约 59.4 GB/s，AVX-512 实测超 130 GB/s，接近 memcpy非加密，不防对抗C/Rust/Go/Java/Python 绑定齐全内存去重、缓存键、大文件快速比对
MD5 / SHA-1遗留加密哈希中速均已被实际攻破存量巨大但新项目应弃用仅遗留系统兼容
SHA-256 / SHA-512加密哈希数百 MB/s抗碰撞，通用对抗标准极广：TLS、Git、IPFS、证书链防篡改、签名、内容寻址
BLAKE3加密哈希（Merkle 树结构）单核约 2.4 GB/s；多核 + AVX-512 可达 10+ GB/s，约为 SHA-256 的 15–27 倍抗碰撞，流式/并行友好2020-01-09 发布，各主流语言绑定增长中大文件、大吞吐场景下的"真"完整性校验
文件系统块级校验（ZFS/Btrfs）端到端块校验 + 自愈写入时算、读取时验，有冗余时可自愈防静默损坏（bit rot、错位读写）ZFS/Btrfs 生产广泛存储层兜底

分组说明：六条路线按三层组织——速度层（CRC32/CRC32C、xxHash）、密码学层（MD5/SHA-1 为退役一代，SHA-256/SHA-512 与 BLAKE3 为现役两代）、存储层（ZFS/Btrfs 块级校验），下文按层展开。

速度层（CRC32C 与 xxHash）：xxHash 官方基准显示 XXH3_64 在 AVX2 机器上约 59.4 GB/s，AVX-512 平台实测超过 130 GB/s，逼近甚至超过内存拷贝带宽（xxhash.com 基准）；CRC32C 依靠 CPU 硬件指令也能达到 10–30 GB/s 量级。但两者都不具备抗碰撞性——它们防的是宇宙射线般的随机位翻转，不防恶意篡改（xxHash vs BLAKE3 对比、CodeSector 校验和格式指南）。

密码学层（SHA-256 与 BLAKE3）：SHA-256 是"防篡改"的通用答案，但速度只有数百 MB/s；BLAKE3 用 Merkle 树结构把加密哈希做到单核约 2.4 GB/s、多核 AVX-512 下约 10+ GB/s，官方仓库口径约比 SHA-256 快 15–27 倍（xxHash 仓库基准讨论 #660、BLAKE3 官方仓库）。注意速度倍数存在两种口径：裸哈希多核并行下 15–27×（BLAKE3 官方基准），文件系统集成场景下 OpenZFS 2.3 官方口径约 3×（Phoronix）——集成开销与 I/O 瓶颈会吃掉裸哈希优势。MD5 与 SHA-1 已被实际攻破（SHAttered，2017-02-23，一手来源见纵轴阶段五），新系统应弃用。选型口诀：防随机错用 CRC32C/XXH3，防人（对抗）用 SHA-256/BLAKE3，两者不可互相替代。

存储层（ZFS/Btrfs 端到端校验）：UW–Madison 在 FAST '10 的经典论文《End-to-end Data Integrity for File Systems: A ZFS Case Study》证实 ZFS 能有效检测静默损坏（bit rot、幻影写、错位读写），但也指出了磁盘与内存之间传输的盲区（论文 PDF）。ZFS 对数据与元数据全量校验，有镜像/RAID-Z 冗余时可自愈并支持 scrub 全盘巡检；而 ext4/NTFS 默认不校验数据内容，可能把坏数据静默返回给应用（Btrfs vs ZFS 对比）。Btrfs 默认 CRC32C，但支持切换 xxhash/sha256/blake2 等更强算法。关键提醒：没有 ECC 内存时，连 ZFS 也无法闭环——内存里的损坏发生在校验计算之后（Reddit r/zfs 讨论）。

横轴结论（校验和）：2026 年的格局是"三层分工"——硬件（CRC32C 指令、ECC）负责便宜的随机错检测，文件系统（ZFS/Btrfs）负责端到端兜底，应用层用 BLAKE3/SHA-256 负责"我 care 的那份数据"的强校验。xxHash 与 BLAKE3 的出现让"快"与"强"不再必须二选一——这是近五年该子领域最大的格局变化。

2.4 子领域二：内容寻址——"内容即身份"的六种实现

方案寻址单位哈希算法标识符自描述性去重防篡改生态/成熟度典型场景
Git 对象库对象（blob/tree/commit）SHA-1（历史）/ SHA-256（可选）无（算法固定于仓库）天然按内容去重依赖哈希 + 签名开发者全员，极高源码版本管理
IPFS CID任意块（blob/chunk）默认 sha2-256，multihash 可扩展强（multibase+版本+multicodec+multihash）按 CID 去重哈希即校验Web3/分发领域成熟去中心化分发、算法可演进场景
resticCDC 分块加密后 SHA-256中内容定义分块去重认证加密（防篡改+防泄漏）备份圈主流加密去重备份，任意后端
BorgCDC 分块分段 CRC32 + 加密中存储效率口碑更强（去重 + 可调压缩）认证加密备份圈主流高压缩比、同机仓库
Bazel 远程缓存（CAS）动作输入/输出SHA-256中（协议化）天然去重依赖哈希构建系统标配构建加速
Nix / OSTree 存储包/文件树SHA-256中不可变存储 + GC不可变性DevOps 成熟可复现部署、系统树版本化

分组说明：六种实现归为四类展开——版本管理（Git）、去中心化分发（IPFS）、备份仓库（restic 与 Borg 合算一路）、构建与部署（Bazel CAS 与 Nix/OSTree 合算一路）。

Git 对象库：哈希即对象 ID，内容寻址的最小可行实现。历史上固定 SHA-1；2020 年 10 月 Git 2.29 引入实验性 SHA-256 对象格式（Phoronix），社区计划在 Git 3.0 设为默认，但痛点在存量仓库与生态——SHA-1 与 SHA-256 仓库之间至今无法互相 push，主流托管平台尚未支持 SHA-256 仓库，第三方工具又常假定 40 字符哈希；LWN 记录互操作补丁自 2020 年提出后始终未合入、Git 2.31（2021-03）后再无实质进展，维护者甚至直言"暂不建议用于正经项目"（LWN: Whatever happened to SHA-256 support in Git?）。这暴露了内容寻址系统的通用难题：哈希算法写死在标识符里，升级即意味着迁移。

IPFS CID：与 Git 相反，CID 被设计为自描述标识符——multibase 编码 + 版本号 + multicodec 内容类型 + multihash（算法自描述），因此哈希算法可以逐标识符演进而不破坏系统，默认算法为 sha2-256；注意 CID 不是裸哈希，sha256sum 的输出与 CID 不一致（IPFS 官方文档：Content Addressing、CID 规范、Filebase: CID 结构拆解）。这是 Git 与 IPFS 最本质的架构分歧：固定算法换简单 vs 自描述换可演进。

restic 与 Borg（备份即内容寻址）：两者都用内容定义分块（CDC）做去重（思想源头即纵轴阶段三的 LBFS，SOSP '01），都用认证加密保证"篡改可检测"——restic 使用 AES-256-CTR + Poly1305 / ChaCha20-Poly1305。差异在：Borg 在存储效率上口碑更强（分块更细 + lz4/zstd/zlib/lzma 可调压缩），但通常要求远端主机装有 Borg 二进制；restic 的仓库可放在任意通用后端（S3、SFTP 等），默认 zstd 压缩后与 Borg 的效率差距在常见数据上已明显缩小（restic vs Borg 对比、Borg check 文档）。borg check --verify-data 做全量数据校验，而默认只校验分段 CRC32（restic 论坛：CDC 去重的安全性讨论）。

构建与部署侧（Bazel CAS、Nix、OSTree）：Bazel 远程缓存由两部分组成——action cache（动作哈希 → 结果元数据映射）与 content-addressable store（Bazel 官方文档：Remote Caching、EngFlow: The Many Caches of Bazel）；开源实现 bazel-remote 直接以小写 SHA-256 为键的扁平不可变存储（bazel-remote）。Nix store 与 OSTree 同属"不可变哈希寻址存储 + GC"的部署流派（横轴稿标注：此句部分基于模型既有知识归纳，检索以 Bazel 侧为准；Nix 的原始出处见纵轴阶段四的 Dolstra 博士论文）。

横轴结论（内容寻址）：内容寻址 = 完整性 + 去重 + 不可变性三合一，是"校验和"子领域的自然延伸。但它只保证读路径的完整性：写入中断产生的半成品对象要靠原子写入兜底（衔接 2.5 节）；对象引用关系形成的图需要 GC，而"正在被引用"的判断又需要文件锁（衔接 2.6 节）——五个子领域在此咬合。

2.5 子领域三：原子写入——从"四步舞"到硬件原子

方案原子性保证持久性手段跨平台成熟度适用场景
temp+fsync+rename 手工模式POSIX rename 原子替换fsync 临时文件 + fsync 目录POSIX 系（Windows 需另换原语）极高但正确实现稀少配置文件、状态文件更新
语言库（write-file-atomic / os.replace / rust-atomicwrites）同上，封装正确细节库内处理 fsync多数覆盖双平台高应用层默认选择
Windows MoveFileEx / ReplaceFileNTFS 上原子替换MOVEFILE_WRITE_THROUGHWindows高Windows 端原子替换
Linux RWF_ATOMIC块层"不断裂写"（单次 I/O 原子）硬件保证，随写随持久语义Linux 6.11+，需 NVMe/SCSI 支持新兴（2024–2025）数据库大块写入
SQLite / LMDB事务级 ACID/快照WAL/journal/COW 全套极广极高结构化状态，"别手写舞步"的替代

POSIX 四步舞及其陷阱：标准模式是 ① 同目录写临时文件（保证同文件系统，rename 才原子）② fsync 临时文件 ③ rename 覆盖目标 ④ fsync 目录（保证 rename 本身落盘）。这条要求写进了手册页：fsync(2) 明确指出"调用 fsync() 并不保证文件所在目录的目录项也已落盘，为此需要对目录描述符再显式调用一次 fsync"（man7 fsync(2)）；大量应用在 rename 前不做这一步、崩溃后新文件零长度或消失的后果，由社区问答与断电实测共同记录（unix.SE: Is it "broken" to replace a file without fsync()?；断电实测见第一节阶段五 Dan Luu《Files are hard》）；Python 社区在 bpo-8828 中同样确认 rename 原子但持久性需目录 fsync（Python issue 8828）。这里正是"原子性 ≠ 持久性"的最典型案例：rename 买的是 atomicity，fsync 买的才是 durability。 这套协议并非纸上谈兵——纵轴显示它是 2009 年 O_PONIES 之争被内核拒绝后、经 2015 年 Dan Luu 断电实测与 2018 年 fsyncgate 反复背书的"血写标准"（见第一节阶段五）。

语言库封装：Node 生态的 write-file-atomic 完整实现 temp+fsync+rename（npm/write-file-atomic）；Python 的 os.replace 在 POSIX 与 Windows 上均为原子替换但持久性需自行处理（Atomic File Save Patterns、LWN: A way to do atomic writes）。

Windows 原语：Windows 没有 POSIX rename 语义，候选是 MoveFileEx(MOVEFILE_REPLACE_EXISTING) 与 ReplaceFile（后者保留目标 ACL/属性）；微软在弃用事务性 NTFS（TxF）后的官方指引就是"写新文件再替换"（Microsoft Learn: TxF 弃用、SO: Is an atomic file rename (with overwrite) possible on Windows?）。2026 年的共识进一步收敛：NTFS 上"持久原子替换"是单次调用 MoveFileEx(MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH)，不应把 POSIX 的 fsync-目录模式照搬过去（luth.io: Atomic File Replacement on NTFS Is Not rename + fsync）。

内核与硬件路线（当下时间截面最重要的变化）：Linux 6.11（2024）引入块层原子写，向用户态暴露 RWF_ATOMIC 标志，覆盖 SCSI/NVMe（Phoronix: Linux 6.11 Block Atomic Writes）；6.13 进一步扩展数据库相关的原子块写支持（LWN: Support for atomic block writes in 6.13）；ext4 已在内核文档中正式描述原子（不断裂）块写，XFS 亦已支持，Oracle UEK8 内核已随附（内核文档: ext4 atomic writes）。重要语义：用户态传入 RWF_ATOMIC 而硬件不满足对齐/大小约束时，内核直接报错而非静默降级——这是"宁可失败不可撒谎"的设计取向，与本领域历史上大量隐性降级（见交叉洞察）形成鲜明对照。

替代方案：如果状态是结构化的（多个键、需要事务），正确答案往往是"直接用 SQLite 或 LMDB"，而不是手写四步舞——详见 2.7 节。

横轴结论（原子写入）：2026 年的原子写入格局呈现明显的双轨制——应用层小文件继续用 rename 舞步（库封装成熟）；数据库级大写入开始从"日志 + fsync 舞步"迁移到硬件原子写（RWF_ATOMIC）。跨平台方面，Windows 与 POSIX 语义不可简单互译，这一缝隙由跨平台库填补，也是实际工程中最常见的 bug 来源。

2.6 子领域四：文件锁——并发互斥的三代方案与 Windows 支线

方案锁归属崩溃自动释放字节范围NFS/分布式主要坑成熟度
flock（BSD）绑定打开文件描述（open file description）是（内核锁）整文件NFS 上与其他锁互操作性依内核版本fork 共享 fd 则共享锁数十年
fcntl/lockf（POSIX 记录锁）按进程 + 字节范围是是映射到 NLM 协议关闭该文件的任何一个 fd 即释放全部锁（经典事故源）数十年
O_EXCL / 锁文件约定文件存在性否（崩溃留陈旧锁）无可用于部分分布式 FS陈旧锁需超时检测高
Windows LockFileEx句柄 + 字节范围是是SMB 配合仅字节范围锁，不解决原子替换高
跨平台库（filelock / portalocker / fasteners / proper-lockfile）封装上述原语内核锁路线：是；锁文件路线：需检测部分视路线而定双路线语义不同，混用即坑高

分组说明：表中五行按脉络归组——flock 与 fcntl/lockf 同属第一代"内核建议锁"；O_EXCL 锁文件为第二代"锁文件约定"；跨平台库为第三代"封装层"；Windows LockFileEx 不属于这条 Unix 脉络的任何一代，而是与 Unix 建议锁平行的另一套 OS 原语（Windows 没有 flock），下文单独展开。

flock 与 fcntl 的经典分歧（纵轴阶段二与横轴在此重复叙述，正文只述一次）：两者都是 advisory 锁（进程可以无视），但语义差异是几十年来 bug 的头号来源——flock 绑定打开文件描述，fork 出的子进程共享同一把锁；fcntl 锁按进程持有，只要关闭指向该文件的任意一个 fd（哪怕是你自己另开的），进程持有的所有 fcntl 锁全部释放（man7: flock(2)、apenwarr: Everything you never wanted to know about file locking、0pointer: On the Brokenness of File Locking）。部分 OS 让 flock 与 fcntl 共享同一锁表，Linux 则基本独立（NFS 上有模拟），跨平台混用会静默失效而非报错（gavv: File locking in Linux、unix.SE: flock vs fcntl over NFS）。纵轴补上历史的最后一笔：2021 年 Linux 5.15 移除强制锁后，建议锁成为唯一正道——40 年演进以"做减法"收尾。

锁文件约定（O_EXCL）：最可移植（Windows、部分分布式文件系统都可用），但崩溃后留下陈旧锁是结构性缺陷。Node 生态的 proper-lockfile 用 mtime 心跳 + 超时检测来恢复陈旧锁，是与纯内核锁路线的根本差异（moxystudio/node-proper-lockfile）。

Windows LockFileEx 支线：Windows 没有 flock/fcntl，等价原语是 LockFileEx——锁绑定文件句柄、按字节范围、可选独占（LOCKFILE_EXCLUSIVE_LOCK）与"抢不到立即失败"（LOCKFILE_FAIL_IMMEDIATELY）；进程终止或句柄关闭时由操作系统释放锁，崩溃语义与 flock 同级（Microsoft Learn: LockFileEx function）。两个工程要点：① 它只解决并发互斥、不解决原子替换——"先 LockFileEx 锁住、写临时文件、再 MoveFileEx 替换"才是完整配方（见 2.9 节配方一与配方四）；② 该函数在 SMB 3.0 上受支持、可用于共享文件场景，但跨主机互斥仍需应用层方案。与 POSIX 侧同理，实际工程不建议手写 LockFileEx，portalocker、filelock 等库已在内部按平台分发到 flock/LockFileEx/锁文件（见下文跨平台库矩阵）。

跨平台库矩阵（2026 年现状）：Python 侧——filelock 提供双模式：FileLock（内核锁，崩溃自动释放）与 SoftFileLock（纯锁文件，可能陈旧）（py-filelock 文档）；portalocker 包装 flock/lockf/Windows LockFileEx，支持超时与 Redis 后端（wolph/portalocker）；fasteners 提供进程锁并天然免陈旧锁（fasteners 文档）。值得注意的是 Python 标准库至今没有内置 IPC 锁文件原语，社区讨论仍在进行（discuss.python.org 帖子）——"锁"这一基础能力仍散落在第三方库里。

横轴结论（文件锁）：文件锁只解决并发、不解决崩溃：锁文件的存在性判断在崩溃后不可信，所以现代方案分化为两条明确的路线——内核锁（崩溃自动释放、免维护，但不能跨机器）与锁文件 + 陈旧检测（可跨文件系统语义、但要付心跳/超时的复杂度）。选型第一问是"进程崩了之后，锁还在不在？在就是 bug"。

2.7 子领域五：崩溃恢复——四种恢复哲学的对决

方案恢复机制崩溃后需要重放吗持久性语义代价成熟度
SQLite rollback journal（默认）就地 B 树 + 回滚日志需（回滚未完成事务）COMMIT 返回即在盘写两次（数据+日志）极高
SQLite WAL预写日志 + checkpoint需（重放 WAL）WAL 模式默认 synchronous=NORMAL：只防进程崩溃、不防断电；FULL 才防断电顺序写 WAL，读并发好；>100MB 大事务性能差极高
LMDB COW B+树写时复制 + 双根提交，永不覆盖活动页不需要（旧树始终完整，结构性免疫）依赖写后 fsync写放大（页拷贝）高
Redis AOF追加日志 + 三档 fsync需（重放 AOF）appendfsync always/everysec(默认)/no，everysec 崩溃约丢 1 秒日志体积与重放时间极高
文件系统日志（ext4 journal / NTFS）元数据（可选数据）日志文件系统自行重放保证文件系统结构一致，不校验数据内容写放大极高

分组说明：表中五行归入四种哲学——SQLite 的 rollback journal、SQLite WAL 与 Redis AOF 三行同属"日志重放"（前两者是提交日志的回滚/重放，AOF 是追加重放，档位各不同）；LMDB 一行是"结构免疫"；文件系统日志一行是"底座兜底"；第四种哲学"硬件原子"（RWF_ATOMIC）暂无表格行——它是 2.5 节的新路线，尚在普及初期。

SQLite：持久性档位是最常见的"语义错觉"。WAL 模式（纵轴：2010-07-21 由 3.7.0 引入）把提交从多次 fsync 压缩为一次（先写 WAL、fsync WAL、再择机 checkpoint 回主库）（SQLite 官方 WAL 文档、SQLite atomiccommit 文档）。但 WAL 模式下默认 synchronous=NORMAL，事务在进程崩溃后存活，在断电后可能丢——要防断电必须显式设 synchronous=FULL（avi.im: SQLite commits are not durable under default settings）。SQLite WAL 对超过约 100MB 的大事务性能不佳（SQLite WAL 文档）。这是"以为买了 A 其实只买了 B"的最典型样本：原子性默认满配，持久性默认降档。

LMDB：结构性免恢复。COW 设计永不覆盖正在使用的页，配合双根提交，崩溃后数据库"结构上不可能损坏"，无需任何重放/修复过程（Wikipedia: LMDB、lmdb.tech 文档、How LMDB works）。代价是写放大；收益在读路径——Mozilla rkv 设计评审的基准中 LMDB 顺序读最多达 SQLite 的 47 倍（Mozilla rkv design review）。它代表与 WAL 完全相反的哲学：不写日志，用数据结构本身换取恢复的消失。

Redis AOF：持久性是可调价格而非布尔值。appendfsync always（"very very slow, very safe"）、everysec（默认，崩溃最多丢约 1 秒，后台 fsync 线程滞后时实际可到 1–2 秒）、no（交给 OS）（Redis 官方持久化文档、crash recovery 详解）；4.0+ 的混合持久化（RDB 骨架 + AOF 增量）兼顾恢复速度与丢失窗口。Redis 明示即便 always 也不能保证零丢失——真正零丢失需要副本与共识层。

文件系统日志是底座不是答案：ext4 默认 data=ordered 只保证元数据一致，NTFS 同样；它们保证"文件系统结构不烂"，不保证"你的数据内容没错"——因此必须与 2.3 节的块级校验互补，而非互替。

横轴结论（崩溃恢复）：四种哲学——日志重放（SQLite/Redis）、结构免疫（LMDB）、硬件原子（RWF_ATOMIC）、底座兜底（FS 日志）——没有全能冠军：日志重放通用但默认档位有陷阱，结构免疫优雅但有写放大，硬件原子最快但需要新硬件与新内核。选型的第一问始终是：你要防的是进程崩溃还是断电？两者的价格完全不同。

2.8 选型速查（决策树式）

2.9 落地配方：把决策树变成可复制的最小代码

下面四个配方覆盖大部分日常场景；每个配方都对应 2.1 节"三种语义"中的一条或多条，并给足 Windows 分支——Windows 不是脚注，而是每个配方的一等分支。代码以 Python 为主（标准库可跑），要点对其他语言同样适用。

配方一：小文件原子写入（POSIX 四步舞 + Windows 变体）

# atomic_write.py —— Python 3.8+，POSIX 与 Windows 双分支
import os, sys, tempfile, ctypes

def atomic_write(path: str, data: bytes) -> None:
    """原子替换 path 的内容。
    POSIX 侧：四步舞（同目录临时文件 → fsync 文件 → rename → fsync 目录）。
    Windows 侧：单次 MoveFileExW(REPLACE_EXISTING | WRITE_THROUGH) 完成持久原子替换。
    """
    d = os.path.dirname(os.path.abspath(path))
    fd, tmp = tempfile.mkstemp(dir=d, prefix=".tmp-")
    try:
        with os.fdopen(fd, "wb") as f:
            f.write(data)
            f.flush()
            os.fsync(f.fileno())            # ① 同目录临时文件  ② fsync 文件（持久性）
        if sys.platform == "win32":
            # ③ NTFS 的"持久原子替换"是单次调用（不要照搬 fsync-目录舞步）
            MOVEFILE_REPLACE_EXISTING = 0x1
            MOVEFILE_WRITE_THROUGH    = 0x8
            move = ctypes.WinDLL("kernel32", use_last_error=True).MoveFileExW
            move.argtypes = (ctypes.c_wchar_p, ctypes.c_wchar_p, ctypes.c_uint32)
            if not move(tmp, path, MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH):
                raise ctypes.WinError(ctypes.get_last_error())
        else:
            os.replace(tmp, path)           # ③ POSIX：原子替换（原子性）
            dfd = os.open(d, os.O_RDONLY)   # ④ fsync 目录：让 rename 本身落盘（持久性）
            try:
                os.fsync(dfd)
            finally:
                os.close(dfd)
    except BaseException:
        try:
            os.unlink(tmp)
        except OSError:
            pass
        raise

语义对照（回到 2.1 节框架）：rename/os.replace/MoveFileEx 买的是原子性；fsync 文件、fsync 目录（POSIX）与 MOVEFILE_WRITE_THROUGH（Windows）买的才是持久性——对应 fsync(2) 手册页的目录项要求（2.5 节）。生产环境别手写：Node 直接用 write-file-atomic（内部即 temp+fsync+rename，npm/write-file-atomic）；Python 把上面 20 行封成 util；Rust 用 atomicwrites。另外 Windows 上 Python 的 os.replace 只承诺原子替换、没有 WRITE_THROUGH 选项，防断电场景走上面的 ctypes 单调用变体或 ReplaceFile（保留目标 ACL/属性时）。

配方二：SQLite 防断电完整配置（WAL + FULL）

-- 每次打开连接后立即执行：
PRAGMA journal_mode = WAL;        -- WAL 模式：读写并发 + 原子提交（写入库文件、持续生效）
PRAGMA synchronous  = FULL;       -- 关键档位：NORMAL 只防进程崩溃，FULL 才防断电
PRAGMA wal_autocheckpoint = 1000; -- 可选：每 1000 页自动 checkpoint（默认值）
-- 自查：PRAGMA synchronous; 应返回 2（FULL）

档位语义矩阵（SQLite 官方文档口径，见 SQLite PRAGMA 文档）：

synchronous回滚日志模式WAL 模式
EXTRAACIDACID
FULL可能不持久ACID
NORMAL可能不一致可能不持久（事务在进程崩溃后存活、断电后可能回滚）
OFF不一致不一致

三个操作要点：① synchronous 是连接级设置、不随库文件持久化，每个连接都要重设（journal_mode=WAL 则持久）；② 只防进程崩溃（SIGKILL）时 NORMAL 即可，防断电/OS 崩溃必须 FULL；③ 档位受编译选项与发行版影响（macOS 系统自带 SQLite 默认档位有差异），务必显式设置后用 PRAGMA synchronous; 自查（avi.im: SQLite commits are not durable under default settings）。Python 侧两行接入：

import sqlite3
con = sqlite3.connect("app.db")
con.execute("PRAGMA journal_mode = WAL")
con.execute("PRAGMA synchronous = FULL")   # 防断电；只防进程崩溃可省

配方三：校验和三问（存哪 / 何时验 / 坏了怎么办）

# 最小巡检配方（POSIX；清单与数据分开存放）
find data/ -type f -exec sha256sum {} + > manifests/data.sha256
# 定期巡检（cron/计划任务），只打印损坏行
sha256sum -c manifests/data.sha256 | grep -v ': OK$'
# Windows 侧单文件校验可用 PowerShell Get-FileHash 或 certutil -hashfile <文件> SHA256

配方四：多进程互斥（POSIX flock 与 Windows LockFileEx）

# POSIX：内核锁，进程死自动释放，无需陈旧锁清理
import fcntl, os

lock_fd = os.open("/var/run/job.lock", os.O_CREAT | os.O_RDWR)
fcntl.flock(lock_fd, fcntl.LOCK_EX)   # 阻塞等待；LOCK_NB 则抢不到立即抛 BlockingIOError
try:
    ...                               # 临界区
finally:
    fcntl.flock(lock_fd, fcntl.LOCK_UN)
    os.close(lock_fd)
# 跨平台（含 Windows）：推荐走库，由库按平台分发到 flock / LockFileEx / 锁文件
import portalocker

with portalocker.Lock("job.lock", timeout=10) as fh:
    ...                               # 临界区；退出上下文即释放（异常时同样释放）

Windows 原生语义（库内部做的事）：LockFileEx 绑定句柄、按字节范围、独占/共享可选，进程终止或句柄关闭时由 OS 释放（见 2.6 节 Windows 支线）——与 flock 的"崩溃自动释放"同级。portalocker.Lock 在等待超时后获取锁、退出上下文即释放（portalocker 文档，用法已对照官方示例核实）。选型判断题仍是那句：进程崩了之后，锁还在不在？内核锁路线答"不在（正确）"，锁文件路线答"还在（陈旧锁，需心跳/超时检测）"（对应 2.6 节结论）。

三、交叉洞察：两轴结合说明了什么

3.1 六条合并去重后的共识

  1. 故障模型下移、防御上移，端到端论证被三个十年反复兑现——且横轴证据表明它至今仍未"毕业"。 纵轴的主线一（RAID 被打穿 → ZFS 端到端校验 → S3 默认 CRC）在横轴上得到当代注脚：Meta 在数十万机器规模上发现"静默出错的 CPU"——每数千颗处理器中即约有一颗存在不触发任何报警的计算错误（Meta engineering blog, 2021，相关论文 *Cores that don't count*, HotOS '21, arXiv:2102.11245）；Google 2009 年的 DRAM 大规模田野研究显示内存错误远高于预期且以硬错误为主（Schroeder et al., 2009）；微软研究院 2012 年的《Cosmic Rays Don't Strike Twice》基于近 300 TB-年的生产内存数据进一步指认：相当大比例的现场错误是硬错误而非偶发宇宙射线（ASPLOS 2012，见参考来源）；而横轴还指出"没有 ECC 内存时连 ZFS 也无法闭环"。结论：即使有 ECC、有 ZFS，关键数据仍应做应用层端到端校验（内容寻址或显式 checksum），因为每一层都只覆盖自己之后、下一层之前的那段路径。 两轴交叉的价值正在于此：纵轴证明"信任中间层"每次都输，横轴证明中间层今天仍在静默出错。
  1. 三种语义分开买，且默认档位普遍降档——这不是理论风险，而是被纵轴事故史反复验证的现实。 横轴的框架（rename 给 atomicity 不给 durability；WAL+NORMAL 给 atomicity 不给 power-loss durability；CRC32C 给 integrity 不给对抗性）与纵轴的事故编年严丝合缝：2009 年 O_PONIES 之争是"应用想买 durability、内核拒绝代买"的分水岭；2015 年 Dan Luu 用断电实测证明跳过 fsync 的 rename 在真实文件系统上丢数据；2018 年 fsyncgate 曝出内核把 fsync 错误"上报一次后丢弃"，PostgreSQL"错误使用 fsync 达 20 年"。数据完整性工程的一半工作量，是把 Integrity/Atomicity/Durability 三个词从"感觉安全"变成逐条指认由哪个机制、在什么档位、覆盖哪类故障。
  1. 哈希从检错到身份是 70 年里最大的一次范式迁移，而横轴显示这次迁移还在升级。 纵轴主线三（CRC 检错 → MD5/SHA-1 认证并两次退位 → SHA-2/BLAKE3 时代哈希成为地址与账本）与横轴的内容寻址格局拼成完整图景：Git 把算法写死在仓库里（升级即迁移，LWN 记录的转换困境），IPFS CID 用 multihash 让算法自描述、可逐标识符演进——"身份即证明"的下一步是"身份可换证明算法"。同样的自描述化也出现在账本侧：RFC 6962 日志 2025 年起退役、转向算法可演进的 Merkle Tree Certificates 草案。
  1. 两轴共同指向同一个收敛方向：更快、更自描述、更少隐式假设。 横轴洞察（校验和从"快与强二选一"走向 BLAKE3"又快又强"；内容寻址从算法写死走向 CID 自描述；原子写入走向 RWF_ATOMIC"硬件保证 + 不满足即报错"；备份从裸仓库走向认证加密仓库）在纵轴上都能找到时间锚点：2019–2025 年这四条线几乎同步完成了一次"显式化"升级——校验和侧 S3 把默认校验做成零成本（2022）、OpenZFS 2.3 直接采用 BLAKE3（2025）；身份与协议侧 RFC 9530 把摘要算法显式写进标准字段（2024）；原子写入侧 Linux 6.11 的 RWF_ATOMIC 宁报错不撒谎（2024）；备份侧的认证加密仓库（restic/Borg）在此前十年已定型为默认（见第一节阶段五）。当一层防线无法被显式指认时，它正在被移除；当一层防线无法被绕过时，它正在变成默认。
  1. 五个子领域在实际系统里是咬合的，不存在单点最优。 横轴的咬合链（内容寻址的写入需要原子替换兜底半成品对象；引用计数的并发修改需要文件锁；锁的崩溃语义决定是否需要陈旧检测；崩溃恢复机制决定持久性档位；机制的终点都需要校验和闭环验证）与纵轴的样板互相印证：SQLite 的五态锁 + WAL、Git 的 lockfile + 对象哈希 + fsync 协议，都是"五件套各自就位"的整体设计——页级校验和则是 PostgreSQL 9.3（2013 年）起的能力（见第一节阶段四）。评估任何一个"数据完整性方案"时，应画出它在这五个位置各取了什么、什么没取。
  1. 跨平台语义差是持续性成本中心，答案是收敛到少数经过验证的库。 flock/fcntl 语义分歧（关 fd 即放锁）、Windows 单调用 MoveFileEx vs POSIX 四步舞、LockFileEx 的字节范围模型——每一处都产生真实事故与专门的库。2026 年的实践共识：这类底层语义差异应收敛到 write-file-atomic、fasteners、portalocker、proper-lockfile 等少数经过验证的库，而不是在每个项目里重新发明；纵轴的教训（fsyncgate 之前 PostgreSQL 也自认为用法正确）说明"自己写"的隐含成本远高于引库。

3.2 对用户的判断与建议

第一，把"三种语义清单"当作任何写路径设计的必答题。 上线前逐条写下：这份数据防谁（随机错/篡改）→ 由谁检测（CRC32C/XXH3 还是 SHA-256/BLAKE3）；读者会不会看见半成品 → 谁保证原子性（rename/RWF_ATOMIC/WAL）；断电后丢多少 → 谁保证持久性、在什么档位（fsync 协议 / synchronous=FULL / AOF 档位）。回答不了任何一条，就是下一个 fsyncgate。

第二，按 2.8 节决策树选型，不要在体系外发明新原语。 防随机错 CRC32C/XXH3、防篡改 SHA-256/BLAKE3 不可互替；小文件替换直接用语言库；结构化状态直接上 SQLite（检查 WAL 档位）或 LMDB；多进程互斥优先内核锁（POSIX 走 flock/portalocker，Windows 走 LockFileEx 语义的库封装，见 2.9 配方四）。特别注意 SQLite 的默认档位陷阱：WAL + NORMAL 只防进程崩溃，防断电须显式 synchronous=FULL。

第三，端到端校验不可省，且要覆盖"存储层校验看不见的路径"。 即使已用 ZFS/Btrfs 或云盘，关键数据仍应保留应用层校验（内容寻址或显式 checksum）：Meta 的静默 CPU、Google 的 DRAM 研究、ZFS 与内存之间的盲区都说明中间层会漏。S3 时代应直接用上 CRC32C/SHA-256 请求级校验（2022 年起已零成本默认）。

第四，留意 2026–2030 的换代窗口，新项目不再采用进入退役周期的算法与语义。 SHA-1 已被 NIST 判 2030 年底退役；Git 新仓库应评估 SHA-256 对象格式（存量转换生态未完成，源码仓库迁移需规划）；强制文件锁语义已在 Linux 5.15 移除，任何依赖 -o mand 的老代码都是隐患。

第五，硬件原子写是值得观察但不必抢跑的方向。 RWF_ATOMIC（Linux 6.11+，ext4/XFS，需 NVMe/SCSI 支持）语义干净（不满足即报错），适合数据库级大块写入；应用层小文件在 2026 年的最佳实践仍是"库封装的四步舞"，等硬件普及与文件系统成熟度跟上再迁移。

附录一：综合校准记录（两章矛盾与重复的处理）

  1. BLAKE3 发布年份：横轴表格作"2019 发布"（两处），纵轴给出带来源的 2020-01-09（Wikipedia: BLAKE)、BLAKE3 规格书）。采纵轴 2020-01-09；横轴"2019"应为开发启动/规范筹备期，正文与总览矩阵均已统一为 2020。
  2. SHA-1 碰撞的佐证层级：横轴 2.2 节标注"SHA-1 已于 2017 年被 Google/CWI 公开构造出实际碰撞，此为模型既有知识补充，本轮未单独检索核实"；纵轴阶段五有一手来源（shattered.io、CWI 新闻稿、NIST 回应）。采纵轴带来源版本，横轴处的"既有知识"标注不再保留。
  3. BLAKE3 相对 SHA-256 的速度倍数：横轴引官方仓库口径 15–27×（裸哈希、多核 AVX-512），纵轴引 OpenZFS 2.3 集成口径约 3×。两者测量条件不同（裸哈希并行 vs 文件系统集成开销），正文并列两口径并注明差异，不再当作矛盾。
  4. Git SHA-1/SHA-256 现状的两种表述：纵轴（2.29 实验格式、社区计划 3.0 默认）与横轴（"算法固定于仓库"、转换生态未完成）并非矛盾而是互补，合并为一句：SHA-256 可选格式 2020 年引入、计划设为默认，但存量迁移生态未完成——并保留两侧来源（Phoronix｜LWN 898522）。
  5. SQLite WAL 的双重叙述：纵轴从时间轴讲（3.7.0 于 2010-07-21 引入），横轴从档位语义讲（NORMAL 只防进程崩溃、FULL 才防断电）。合并为一段：时间锚点 + 档位语义同段呈现，来源取并集（SQLite WAL 文档｜avi.im）。

重复合并清单：flock/fcntl 语义分歧与三大锁史文献（man7/apenwarr/0pointer）两章均详述，正文只在 2.6 节详述一次并在纵轴阶段二保留时间轴；FAST '10 ZFS 论文两章均引，正文在历史视角（第一节阶段四）与对比视角（2.3 节存储层）各实质引用一次，参考来源合并去重为一个条目；SQLite WAL/atomiccommit 文档、BLAKE3 规格/仓库、Git SHA-256 来源均已在参考来源合并去重。

附录二：审读修订记录（2026-11-04 定稿）

初稿收到 8 条独立审读意见，逐条修订如下（行号以初稿为准）：

  1. 引用错配（原 L181，硬伤）：经核实，rename(2) 手册页并无"零长度或消失"警告，mount(2) 归属错误。改为引 fsync(2) 手册页原文（"调用 fsync() 并不保证目录项落盘，需对目录描述符显式 fsync"，man7 已核实），unix.SE 保留为社区问答来源，断电实测后果挂回 Dan Luu《Files are hard》。
  2. 计数错误（原 L252）："五条线"改"四条线"，四条线逐一挂时间锚点（S3 2022、OpenZFS 2.3 2025、RFC 9530 2024、RWF_ATOMIC 2024；备份认证加密注明定型于 2010 年代中后期）。
  3. 术语与归属（原 L83/L254）：五态锁在首现处一句话定义（UNLOCKED→SHARED→RESERVED→PENDING→EXCLUSIVE，引 SQLite lockingv3 文档，已核实）；L254 改写为"页级校验和是 PostgreSQL 9.3（2013 年）起的能力"。
  4. 论断不可读（原 L161）：删去"SHA-256 对象可引用任意对象"半句，按 LWN 898522 实际内容改写（两格式仓库无法互相 push、托管平台未支持、40 字符假设、2.31 后无实质进展），均已对照 LWN 原文核实。
  5. 标题数字与表格行数（原 2.3/2.4/2.6/2.7）：2.3 标题改"六条路线"、2.4 改"六种实现"，各表后加分组说明；2.6 标题改"三代方案与 Windows 支线"并补 LockFileEx 正文一段（引 Microsoft Learn 已核实）；2.7 保留"四种哲学"并加归组说明（两行 SQLite + AOF 同属日志重放，硬件原子无表格行）。
  6. 口径与量纲（原 L126/L205/L128/L165）：proper-lockfile 统一为"Node 生态"；LMDB"Monkey"删除，改列可核实用户（Postfix、PowerDNS、Monero，对照 Wikipedia 应用清单）；"约多省 10%"删除——所引 monovm 对比文章中并无此数字，改按该文实际口径"Borg 存储效率口碑更强（去重 + 可调压缩），restic zstd 后差距缩小"。
  7. 附录自述与来源对齐（原 L280/L346/L20）：FAST '10 论文改口径为"历史视角与对比视角各引一次"；孤儿条目《Cosmic Rays Don't Strike Twice》在 3.1 节补正文引用，并补 ASPLOS 2012 出处与出版方页面直链（已核实）；Ritter《The Great CRC Mystery》补作者站点链接（已核实为 Dr. Dobb's Journal 11(2)，1986 年 2 月）并入参考来源。
  8. 落地配方与 Windows 分支（原 2.8 及全文）：新增 2.9 节四个配方（原子写入双平台含 ctypes 的 MoveFileExW 变体、SQLite WAL+FULL 完整配置与档位矩阵、校验和三问含巡检脚本、多进程互斥双平台）；决策树逐条补 Windows 分支（flock 在 Windows 的等价物为 LockFileEx、RWF_ATOMIC 无 Windows 等价等）。配方中的 API 语义（MoveFileEx 旗标 0x1/0x8、LockFileEx 释放时机、portalocker.Lock 用法、SQLite 档位矩阵）均经本次定稿逐条在线核实。

四、参考来源（两章合并去重）

奠基与编码理论

文件系统与崩溃恢复（纵轴史料）

增量同步与内容寻址

校验和与哈希算法

原子写入与持久化协议

文件锁

崩溃恢复与嵌入式存储

数据库与静默损坏研究

块级完整性

*报告生成：2026-11-04，综合报告（纵轴 × 横轴）。全部事实与数字来自两份分轴章节文件（parts/2026-11-04-数据完整性工程-校验和-内容寻址-原子写入-vertical.md 与 parts/2026-11-04-数据完整性工程-校验和-内容寻址-原子写入-文件锁-崩溃恢复-horizontal.md）及其标注来源；两稿各自标注的"背景知识"处沿用原标注；矛盾与重复的处理见附录一校准记录。本文件为最终稿，已按独立审读意见完成 8 条修订（逐条见附录二），初稿存于 drafts/ 未改动。*

← 资料库今日播报 →