【数据存储】压缩存储：长字符串的字典压缩方案

实战应用：用在哪里

发放流水的每行都带着祝福油、强化石、金币礼盒这类重复词，一个月下来流水键占掉的存储比业务数据还多。字典压缩把高频词映射成单字节短码，写入前编码、读取时解码，流水体积直接砍掉六成，业务代码只换两个函数。

字典表与编码解码

字典维护高频词到单字节码的映射，编码时长短词先替换避免子词干扰，解码反向执行，两端共用同一份字典。

local DICT = {
    { word = "金币礼盒", code = "\1" },
    { word = "强化石",   code = "\2" },
    { word = "祝福油",   code = "\3" },
}
local function encode(s)
    for _, d in ipairs(DICT) do
        s = string.gsub(s, d.word, d.code)
    end
    return s
end
local function decode(s)
    for i = #DICT, 1, -1 do
        local d = DICT[i]
        s = string.gsub(s, d.code, d.word)
    end
    return s
end

流水存储的接入与收益

流水写入前先编码，读取展示前再解码，业务逻辑无感知；压缩率埋点按月统计，编码后体积不足原值一半即达标。

local function logFlowEncoded(actor, line)
    local packed = encode(line)
    local day = os.date("%Y%m%d")
    setplayvar(actor, "HUMAN", "FLOW_" .. day, packed, 1)
    return #packed
end

验证与监控

一百条真实流水做编码解码往返测试，解码结果与原文逐字一致；压缩率统计月度均值，低于五成触发字典扩容评审；字典新增词条后旧流水解码回归全量抽查。压缩收益在发放流水、掉落记录与聊天归档三类数据上各自实测，均超过五成。字典表随业务词条扩充需要定期回顾，半年没变过的字典反而说明业务词汇在漂移，更要检查。字典的维护收敛到一张可编辑的表文件，运营加词后跑一遍回归脚本即可上线，不需要研发介入。监控压缩率的月度曲线，连续下滑说明词条表跟不上业务词汇的变化。

踩坑记录

字典顺序影响替换结果，强化石是强化石礼包的子串，先替换短词让长词被切碎无法还原，词条按长度降序排列后解决。控制字符短码在某些展示通道显示为乱码，流水只在存储与解码两端使用短码形态，展示前必先解码。字典新增词条后旧数据解码出错，每段流水头部写入字典版本号，版本不一致时用旧版字典解码。压缩率统计最初把键名也算进原值，虚高了一截，口径统一为只统计流水行内容。