来自 #153 的架构级评审建议。不阻塞合入，仅供参考是否有更好的架构解法。
💡 [建议 · 兼容] LoadSSTableMetaList 中 EnsureMeta 异步 goroutine 对已加载的 SSTable 仍然启动 storage/zstorage/SSTable.go:135
问题根因：当 meta.MaxKeyLoaded=true 时（新格式 SSTable），第 135 行的 go meta.EnsureMeta() 仍然会启动一个 goroutine。从代码可读性看，EnsureMeta 内部应先检查 MaxKeyLoaded 并直接返回，但让整个 goroutine 空转一轮调度仍是浪费。且这发生在每个 SSTable 的加载路径上，本 PR 修复后所有新格式的 SSTable 都走这条路径。
为什么低级解法不够：在 EnsureMeta 内部加一个 if meta.MaxKeyLoaded { return } 是最低成本的修法，也是合理的——但会在每个文件上创建一个无用的 goroutine。
架构级方案：在外层条件判断：if !meta.MaxKeyLoaded { go meta.EnsureMeta() }。这样新格式的 SSTable 完全不启动 EnsureMeta goroutine。同时对 getBlockIndex/getBloom 的异步调用也类似考虑——如果已经在 LoadSSTableMetaList 同步加载了块索引并缓存了（loadBlockIndexFromFile 调用后索引已缓存），那么 go ss.getBlockIndex(meta.Filepath) 中的 getBlockIndex 会立即从缓存返回，产生一次无用的 RLock+Unlock。getBloom 类似。建议在调用异步预热前检查缓存是否已存在。
代价/收益：无代价。这是一个纯优化，消除不必要的 goroutine 创建和锁获取。
💡 [建议 · 兼容] LoadSSTableMetaList 中 EnsureMeta 异步 goroutine 对已加载的 SSTable 仍然启动
storage/zstorage/SSTable.go:135问题根因：当
meta.MaxKeyLoaded=true时（新格式 SSTable），第 135 行的go meta.EnsureMeta()仍然会启动一个 goroutine。从代码可读性看，EnsureMeta内部应先检查MaxKeyLoaded并直接返回，但让整个 goroutine 空转一轮调度仍是浪费。且这发生在每个 SSTable 的加载路径上，本 PR 修复后所有新格式的 SSTable 都走这条路径。为什么低级解法不够：在
EnsureMeta内部加一个if meta.MaxKeyLoaded { return }是最低成本的修法，也是合理的——但会在每个文件上创建一个无用的 goroutine。架构级方案：在外层条件判断：
if !meta.MaxKeyLoaded { go meta.EnsureMeta() }。这样新格式的 SSTable 完全不启动 EnsureMeta goroutine。同时对getBlockIndex/getBloom的异步调用也类似考虑——如果已经在LoadSSTableMetaList同步加载了块索引并缓存了（loadBlockIndexFromFile调用后索引已缓存），那么go ss.getBlockIndex(meta.Filepath)中的getBlockIndex会立即从缓存返回，产生一次无用的 RLock+Unlock。getBloom类似。建议在调用异步预热前检查缓存是否已存在。代价/收益：无代价。这是一个纯优化，消除不必要的 goroutine 创建和锁获取。