LZMW压缩算法实现后数据膨胀问题排查求助

• 字典更新逻辑错误，导致字典爆炸与码长冗余
  你将字典新增逻辑从原LZW的「添加当前未匹配的最长串」改成「添加previous_match与current_data的拼接结果」，完全偏离了LZMW的核心设计。LZMW的字典更新基于最近匹配的前缀复用，而非强制拼接上一个匹配与当前字符。这种改动会让字典迅速充斥大量仅出现一次的冗余条目，既无法提升匹配效率，还会迫使编码提前切换到更长的码长（比如从9位升到16位）。原本8位的原始字节，现在用更长的编码表示，直接带来基础膨胀，再加上冗余条目的额外编码开销，最终导致2.5-3倍的膨胀。

• 输入类型转换引入的匹配效率问题
  将输入从vector<uint8_t>改为string，若处理的是二进制数据（测试数据集多包含二进制文件），会触发两个关键问题：一是string对部分控制字符（如0x00）的处理可能导致字符串截断或匹配逻辑异常；二是字符串的字符匹配基于ASCII编码语义而非原始字节值，大幅降低字典的匹配命中率——原本能匹配的字节序列，转为字符串后无法被正确识别，最终只能逐个输出单个字符的编码，而这些编码的长度远大于原始8位字节。

• 缺失动态码长管理机制
  原LZW实现会随字典规模增长动态调整码长（从初始9位逐步扩展到12位、16位），如果你的LZMW实现未保留该逻辑，全程使用固定长码长（比如一开始就用16位），那么对于大多数数据集，每个原始8位字节都需要用16位编码表示，直接带来100%的基础膨胀，再加上字典冗余的额外开销，最终膨胀倍数就会达到2.5-3倍。

• 匹配逻辑未适配LZMW核心规则
  LZMW的核心是优先复用最近的匹配前缀生成更长匹配串，而你的实现可能仅修改了字典新增逻辑，未调整匹配查找逻辑。比如原LZW是查找最长匹配串，而LZMW需要优先查找以上一个匹配结果为前缀的串。若匹配逻辑仍沿用原LZW方式，新增的字典条目几乎不会被后续数据复用，相当于用更长的码长编码了和原LZW一样的单个字符，自然出现严重膨胀。

内容的提问来源于stack exchange，提问作者MDNick2000