不建议从零手写 Bitcask 引擎用于生产，但用 tiny-bitcask 或 FlyDB 做原型或学习是高效且安全的起点。真正难点在于文件生命周期管理、索引重建容错、并发控制和崩溃恢复——任一环节出错均导致静默数据丢失；Open() 必须校验 DirPath 和 DataFileSize，否则引发 panic 或文件无限膨胀；olderFiles 需参与索引重建与 Get 查找；index.Indexer 必须支持 Delete() 以同步墓碑记录；重启时须按 FileId 升序遍历全部文件，以最后出现记录为准覆盖旧值并清除已删除 key。
直接说结论：不建议从零手写 Bitcask 引擎用于生产，但用 tiny-bitcask 或 FlyDB 做原型或学习是高效且安全的起点。 真正的 Bitcask 实现难点不在追加写逻辑，而在文件生命周期管理、索引重建容错、并发控制和崩溃恢复——这些地方一写错，数据就 silently 丢。
为什么 Open() 时必须校验 DataFileSize 和 DirPath
启动时不做参数校验，后续会触发不可恢复的 panic 或静默损坏。比如 DataFileSize 设为 0，appendLogRecord 中的阈值判断失效，导致单个数据文件无限膨胀；DirPath 为空则 os.OpenFile 直接返回 nil，后续所有 Write() 都 panic。
校验逻辑必须放在 Open() 入口处，不能依赖调用方自觉：
-
if options.DirPath == ""→ 返回errors.New("database dir path is empty") if options.DataFileSize → 拒绝初始化，避免文件切分逻辑瘫痪- 还要检查目录是否可读写：
os.Stat(dirPath)+os.IsNotExist分支处理首次创建
DB 结构体里 activeFile 和 olderFiles 怎么协同工作
这是 Bitcask 文件滚动的核心机制。activeFile 是唯一可写的句柄，olderFiles 是只读的 map[uint32]*data.DataFile，键是文件 ID（通常递增），值是已封存的文件句柄。
关键点在于写入前的判断和切换时机：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 每次
appendLogRecord前，先检查activeFile.WriteOff + size > DataFileSize - 命中阈值后，必须先
Sync()当前文件，再将其移入olderFiles，最后调用setActiveFile()创建新文件 -
olderFiles不参与写，但Get()时要遍历它查找 key —— 所以它的 key 类型必须是uint32而非string，避免 map 查找开销
内存索引 index.Indexer 接口为什么必须支持 Delete()
Bitcask 的删除不是真删磁盘，而是写一个 Type == LogRecordDeleted 的墓碑记录，并在内存索引中立即移除该 key。如果索引接口不提供 Delete()，会导致两个严重问题：
- 后续
Get()仍能查到旧值（因为墓碑没进索引），违反语义 - Compaction 阶段无法识别哪些 key 已被逻辑删除，导致无效数据堆积
- 注意：墓碑记录本身也要写入磁盘，否则重启后索引重建会漏掉这个删除动作
启动时重建索引为什么不能跳过 olderFiles
很多人以为只扫 activeFile 就够了，实际这是最常见数据丢失根源。因为 activeFile 只保存最新一批写入，而历史 key/value 散落在所有 olderFiles 中。索引重建必须按文件 ID 升序遍历全部文件，且对同一 key 要以最后出现的记录为准（覆盖旧值，识别墓碑）。
容易忽略的细节：
- 每个
DataFile必须维护FileId字段，否则无法排序遍历 - 遍历时遇到
LogRecordDeleted类型，必须从索引中Delete(key)，不能仅跳过 - 如果用了
MMapAtStartup，需确保 mmap 区域未被其他进程修改，否则重建结果不可靠
真正难的不是“怎么写”，而是“怎么保证每次重启后索引和磁盘状态严格一致”。哪怕一个 Sync() 漏掉、一个 Delete() 忘调、一个文件 ID 解析错，都会让整个数据库进入不可预测状态。所以优先用 FlyDB 这类经过压测的实现，自己造轮子时务必配全 WAL 校验和启动时 checksum 验证。
