LZW字典增长快、查插频繁，std::map的O(log n)性能不足；推荐预分配vector线性查找或Trie跳转表，位宽需在插入前动态升级而非满时突变。
为什么手写LZW不推荐用 std::map 做字典
因为LZW字典增长极快，且查找/插入频率极高，std::map 的 O(log n) 开销在压缩大量数据时会明显拖慢速度。实际中字典项数常超 4096（12-bit）、8192（13-bit）甚至更多，std::unordered_map 虽为平均 O(1)，但哈希冲突和内存重分配仍带来不可控延迟。更稳妥的做法是预分配固定大小的数组（如 std::vector<:pair uint16_t>>），用线性查找——别笑，LZW 字典前缀特性让常见码字集中在低索引，实测比哈希更快；或者直接用 std::vector 实现 Trie 式静态跳转表（适合 8-bit 输入）。
compress() 中如何正确处理字典溢出与位宽升级
LZW 标准要求输出码字位宽随字典增长动态提升（如从 9-bit 到 10-bit），但很多手写实现只在字典满时“突变”，导致最后一段数据用错位宽解码。正确做法是：在插入新词条前检查当前字典大小是否即将突破 (1 （例如 9-bit 最大值是 511），若插入后会超限，则先输出当前 code，再升级位宽、重置字典（或不清空，仅标记位宽变更），最后才插入新词条。注意：CLEAR 码（通常为 256）必须在每次位宽升级后重新发出，否则解压端无法同步重建字典状态。
- 初始位宽 = 输入符号位数 + 1（如 ASCII 是 8-bit，起始用 9-bit）
- 位宽上限一般设为 12 或 16，到限时停止建新词条，后续只查表输出
- 输出缓冲区必须按位写入，不能直接
write(uint16_t)—— 否则跨字节边界时顺序错乱
解压端怎么避免 code 未定义却强行查表
解压最经典的崩溃点：遇到一个 code 值，字典里还没对应字符串（比如压缩端刚发完 CLEAR 码，又紧跟着一个新词条的编码）。标准解法是——当 code 等于当前字典 size 时，它必然是“上一个字符串 + 自身首字符”的组合。此时需手动构造该字符串：取上一个输出串 s，拼接 s[0] 得到新串，再加入字典。这个逻辑必须放在查表失败之后、抛异常之前执行。
- 不能假设字典索引永远有效，每次
dict[code]前必须校验code - 初始字典要预填 0–255 对应单字节字符，
dict[256]设为 CLEAR，dict[257]为 EOF（如有） - 解压时不维护“当前位宽”，而是根据已读码字数量 & 字典增长历史反推，更可靠
用 std::vector 当 I/O 缓冲时的边界陷阱
压缩输出是比特流，但 C++ 文件/网络 I/O 是字节流。若直接把每个码字转成完整字节存入 std::vector，会浪费空间且无法对齐。正确方式是维护一个位缓冲区（如 uint32_t buffer = 0, int bits_in_buffer = 0），每次 push_code(uint16_t code, int width) 时将 code 左移填入低位，凑够 8 位就 push_back(buffer & 0xFF) 并右移。特别注意：最后不满一字节时，**不要自动补零**——LZW 规范要求截断末尾冗余位，解压端靠字典状态和 CLEAR 码判断流结束，补零会导致解压多出垃圾字符。
- 写入文件前调用
flush()把剩余位转字节，但只写入已用位数（如剩 3 位，就只取buffer & 0x07） - 读取端必须同样用位缓冲解析，不能用
fread(&word, 2, 1, fp)直接读 uint16_t - 跨平台时注意字节序：LZW 是 MSB 在前（big-endian bit order），位移操作无需转换
真正难的不是算法主干，而是位操作与字典状态在压缩/解压两端的严格同步。哪怕只差一个 CLEAR 码位置，或一位宽度没对齐，解压就会雪崩式错乱——这种问题不会报错，只会输出乱码，得靠逐字节比对原始输入才能定位。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
