桥接篇：从练手到交付------四篇博客之后，我回头做了 CacheSQL
先写了一个 2000 行的手写数据库，又写了四篇博客来记录它。写完那一刻觉得"差不多了"。回头一看，发现差远了。
不是代码差------是"练手项目"和"可交付产品"之间的鸿沟。跨越这道鸿沟的过程，成了 CacheSQL。
一、什么留下了
B+ 树内核。256 阶、叶子双向链表、分裂传播、借位合并、二分变体 searchless/searchmore------核心算法全留了。
这些是原型里最对的东西。算法上验证过的，不需要重写。保留内核、外面套工程化层，是最高效的方式。
两个设计也留下了：
软删除。 Row 的 isDelete 标记，O(1) 完成，不移动 ArrayList。手写数据库那篇里讲过，这是删了真删的坑才改的------删了 data.remove(i)，后续元素下标全变，B+ 树存的地址全乱。CacheSQL 里这个设计没变，而且更成熟了：配合 compact() 定期回收已删除行，解决了"一直软删会占满内存"的问题。
预留空间。 节点不填满再分裂，而是 90% 容量时提前分。这个设计在手写数据库的博客里有详细解释------减少后续插入的分裂频率。CacheSQL 里保留了这个策略，因为它确实生效。
二、什么加了
测试
手写数据库那版没有任何测试用例。CacheSQL 加入了 53 项单元测试和 6 项集成测试。不是说加了就高级了------是"交付"的定义变了：不是"你跑通了"，是"别人跑通过了你也安心"。
复制
原型只有单机。加上了主从复制------ReplicationManager、OpLog、SyncClient、SyncServer。设计原则是核心层零修改：Table 和 BPTree 不知道复制的存在。
OpLog 的设计考虑了三个边界：容量固定（环形缓冲区，不无限增长）、序列号递增（Slave 离线可检测覆盖）、upsert 语义（pendingQueue 重放安全）。
HTTP
原型只能 Java 调用。加上了 HTTP，两套引擎：JDK 内置和 Undertow NIO。通过 HttpServerEngine 接口隔离，配置文件切换。
不是为了花哨。是为了让运维脚本、Python 工具、其他服务能查到缓存数据。
文档
原型没有任何文档------代码就是文档。CacheSQL 写了 7 份：功能说明书、部署手册、操作手册、测试报告、性能测试、两版审计报告。加上已有的 4 篇手写数据库博客，形成了完整的技术资产。
SQL 引擎
原型里 SQL 解析是三个静态函数。CacheSQL 拆出了独立的 SqlQueryEngine，加了执行计划缓存和模板化机制：相同 SQL 模板只解析一次。这是从"能解析"到"高效解析"的关键一步。
三、两套博客的关系
手写数据库 4 篇博客是"B+ 树算法教程"。内容密集、有代码片段、有踩坑分析。适合想学 B+ 树的读者------可以跟着写一遍，理解核心数据结构。
CacheSQL 3 篇是"架构工程实录"。内容关于工程决策、抽象设计、取舍权衡。适合做架构的人------看怎么把一个原型包装成产品。
两套博客之间，有一个真实的时间线：写原型 → 写博客 → 发现不够好 → 做工程化升级 → 再写博客。第一套是"学会"，第二套是"做好"。这就是从练手到交付的真实路径。
四、关于 AI 辅助
两套博客和两个项目，全程 AI 辅助。
算法细节的修正------软删除、预留空间------是我在踩坑中自己的总结。代码框架、测试用例、文档结构，是 AI 出力的。
架构决策------ReplicationManager 透明化、OpLog 环形缓冲、upsert 幂等语义------是我做架构多年积累的经验判断。AI 帮我写代码，但不会主动说"这里的写操作需要幂等性保证"。这个判断来自你对"Master 宕机后 Slave 重连可能重复操作"的预判。
用 AI 写代码，用经验做决策。 这是整个 CacheSQL 项目中人与 AI 分工的真实写照。也正是我给同事们讲的"AI 提效"方法论的核心------你的价值在决策，不在执行。
系列：CacheSQL 工程化交付实录（共 5 篇，含桥接篇）
手写数据库系列：（一）起因与架构](https://blog.csdn.net/yuhou25/article/details/160579862?spm=1001.2014.3001.5501)[（二）B+树的插入与分裂（三）删除合并与范围查询]（四）索引引擎、SQL解析与总结]>
CacheSQL 项目：CacheSQL（一）工程化重生CacheSQL（二）主从复制CacheSQL（三）双引擎与SQL查询CacheSQL（四）水平扩展