短字符串指长度较短的字符串，通常用于存储简短文本、标识符或代码片段，具有内存占用小、处理速度快的特点。
短字符串（"user_id" 映射为 'A'，"status" 映射为 'B'，整条 JSON 变成 "A:123,B:active" 这类结构。
为什么短文本不能直接套用 compress/gzip
gzip 和 flate 的最小有效输入通常在 200–500 字节以上：小于这个阈值时，压缩头（gzip header + DEFLATE metadata）本身就占 10–20 字节，加上霍夫曼树开销，输出反而比原文长。实测常见日志字段如 "level":"info"（14 字节）经 gzip 压缩后变成 32 字节。
- Go 的
gzip.NewWriter默认启用 header 和 checksum，无法关闭 -
flate.NewWriter虽可设flate.NoCompression，但仍是流式封装，对单次短输入无意义 - 所有标准库压缩器都假设输入有重复模式和足够长度，短字符串几乎无冗余可榨取
字典编码比压缩更合适：手动映射 + 固定分隔符
适用于协议字段名固定、取值有限的场景（如 IoT 上报、RPC 参数、配置同步），核心是预定义双向映射表，不依赖算法。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 映射表用
map[string]byte（编码）和map[byte]string（解码），避免 runtime.alloc - 分隔符选 ASCII 可见字符（如
'|'、'='），不用0x00避免 C/嵌入式解析歧义 - 原始字符串
"method=ping,code=200"→ 编码后"m=ping,c=200"，压缩率取决于字段名重复率，非统计性压缩 - 若字段值也固定（如
status只有"online"/"offline"），可进一步映射值："s=0"
如何安全集成到 channel 或 net.Conn 流中
字典编码后仍是明文，但体积小、无 header、零延迟，适合高频小包场景；难点在于协议对齐和错误恢复。
立即学习“go语言免费学习笔记（深入）”；
- 别把编码结果再喂给
gzip.Writer—— 纯属叠 buff，增加 CPU 开销且可能破坏格式 - 写入
net.Conn前，加一个固定长度前缀（如 uint16 表示后续字节数），避免粘包；接收端先读 2 字节再解码 - channel 传输时，用
chan []byte而非chan byte，每次发一整条编码后消息，避免切片底层数组被复用污染 - 映射表必须两端完全一致；建议生成 Go const map 并 git commit，而非运行时加载 JSON —— 启动即校验，错配直接 panic
真正的瓶颈不在编码逻辑，而在字段变更时的全链路同步：改一个 key 的映射，设备端、网关、服务端、监控系统全得发版或热重载。比起写十行 map[string]byte，花三天对齐所有端的字典版本才是关键路径。
