rocksdb只接受[]byte而非string，因string不可变且转换需深拷贝，高频操作引发gc压力；key需utf-8编码加前缀隔离，value推荐protobuf序列化以保障兼容性与性能。
为什么不能直接存字符串到RocksDB
RocksDB 是键值对存储，但只认 []byte，不认 string。Go 中 string 是只读的底层字节数组，而 []byte 可变；二者底层结构不同，直接用 string 转 []byte（如 []byte(s)）会触发内存拷贝，频繁操作时有性能损耗。更关键的是：如果 Key 或 Value 含非 ASCII 字符（比如中文、emoji）、或需要支持多字段复合结构，裸存原始字节容易导致解析歧义或版本兼容问题。
Key 编码推荐用 UTF-8 原生 + 前缀隔离
Key 通常用于查询和排序，应保持可读性、可预测性和唯一性。UTF-8 编码天然支持中文等 Unicode 字符，且与 RocksDB 的字节序比较逻辑一致，无需额外序列化开销。
- 纯字符串 Key（如用户 ID）：直接用
[]byte(s)，但务必加业务前缀，例如"user:" + userID→[]byte("user:u123")，避免不同业务 Key 冲突 - 复合 Key（如 “用户+时间戳”）：用分隔符拼接，推荐
'\x00'（NULL 字节）而非":"，因为":"可能出现在原始字符串中，而\x00在 UTF-8 字符串中不会自然出现 - 避免用
encoding/json或gob编码 Key —— 它们输出含非确定性字段顺序或冗余空格，破坏字典序，影响范围查询（如Seek）
Value 编码优先选 Protocol Buffers（不是 JSON）
Value 侧重结构化与向后兼容，JSON 虽易读但体积大、解析慢、无 schema 约束；而 Protobuf 二进制紧凑、反序列化快、天然支持字段增删（通过 optional 和默认值），适合长期演进的业务数据。
- 定义 .proto 文件时，所有字段设为
optional（Protobuf 3.12+），避免旧版本读新数据时 panic - Go 中用
proto.Marshal得到[]byte直接存入 RocksDB；读取时用proto.Unmarshal，注意提前初始化 struct 实例（如&MyMsg{}） - 若 Value 极简（如仅一个字符串），可用
utf8string类型直接存[]byte(s)，但需在文档/常量中明确约定，避免后续扩展困难 - 不要用
gob—— 它依赖 Go 类型名和包路径，跨语言或升级 Go 版本后极易解码失败
编解码层必须封装统一接口，禁止散落调用
实际项目里，Key 和 Value 的编码规则一旦写死在业务代码里（比如几十处 []byte("user:" + id)），后续改分隔符或加加密就会变成灾难。必须抽成可复用的 codec 包。
- 定义
type KeyCodec interface { Encode(key string) []byte; Decode(b []byte) string }，实现类内聚处理前缀、分隔符、转义逻辑 - Value 编解码器应带版本号字段（如 Protobuf message 中加
int32 version = 1;），解码时根据 version 分发到对应解析函数，避免强耦合 - 所有 RocksDB
Put/Get调用前，必须经过 codec 层，禁止业务代码直接构造[]byte - 测试时重点覆盖边界：空字符串、含
\x00的字符串（应被拒绝或转义）、超长字符串（确认截断策略是否一致）
最常被忽略的是 Key 的字节序隐含假设 —— 比如用 strconv.AppendInt 拼时间戳时没补零，导致 "2024-1-1" 和 "2024-10-1" 排序错乱。这类问题上线后很难排查，得在 codec 层强制标准化格式。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
