Go lzw.Writer 写入中文为什么会因 litWidth 太小而失败

compress/lzw 接收的是字节，不是汉字或 Unicode 码点。litWidth 限制原始字面量的取值：每个输入字节都必须小于 1。设为 7 时只能容纳 0 到 127，中文 UTF-8 字节会超出这个范围。对普通 UTF-8 文本压缩，使用 8 位字面量，并让解压端使用相同参数。

官方文档：https://pkg.go.dev/compress/lzw

先区分字面量位宽和字符编码

设想一个导出功能压缩英文状态字段时正常，换成“库存已更新”后 Write 就失败。先不要修改文本编码或删掉中文，应该检查输入字节的范围和压缩器配置。7 位字面量的容量不足，和 Go 字符串能否保存中文是两件事。

litWidth 的允许范围是 2 到 8，它不是压缩等级，也不是 LZW 字典增长后的最大码字宽度。把它调小不能当作通用的节省空间技巧。英文示例偶然处在较小字母表内，并不能证明配置适合后续任意文本。

用同一份中文输入比较两种配置

下面是一个完整的小实验：同一份输入分别使用 7 和 8，然后用匹配的配置解压成功分支，并比较字节。数据都在内存中，不创建文件。示例中的提示是程序运行时自行输出的判断，不是预先声称已经在某台机器上取得的测试记录。

package main

import (
    "bytes"
    "compress/lzw"
    "errors"
    "fmt"
    "io"
    "os"
)

func compress(src []byte, width int) ([]byte, error) {
    if width  8 {
        return nil, fmt.Errorf("字面量位宽须为 2 到 8")
    }
    var dst bytes.Buffer
    w := lzw.NewWriter(&dst, lzw.LSB, width)
    n, writeErr := w.Write(src)
    if writeErr == nil && n != len(src) {
        writeErr = io.ErrShortWrite
    }
    // 无论写入是否成功，都结束本次流；失败时不交付局部压缩结果。
    closeErr := w.Close()
    if err := errors.Join(writeErr, closeErr); err != nil {
        return nil, err
    }
    return dst.Bytes(), nil
}

func run() error {
    src := []byte("库存已更新")
    // 同样的 UTF-8 字节在 7 位字面量范围之外，记录实际返回的错误。
    _, narrowErr := compress(src, 7)
    if _, err := fmt.Fprintf(os.Stdout, "width=7 error=%v\n", narrowErr); err != nil {
        return err
    }
    packed, err := compress(src, 8)
    if err != nil { return fmt.Errorf("压缩: %w", err) }
    // 解压端沿用压缩端的位序与字面量位宽。
    r := lzw.NewReader(bytes.NewReader(packed), lzw.LSB, 8)
    restored, readErr := io.ReadAll(r)
    closeErr := r.Close()
    if err := errors.Join(readErr, closeErr); err != nil {
        return fmt.Errorf("解压: %w", err)
    }
    if !bytes.Equal(src, restored) {
        return fmt.Errorf("往返后的字节不一致")
    }
    _, err = fmt.Fprintln(os.Stdout, "width=8 字节往返一致")
    return err
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

保存为 main.go 后可在自己的 Go 环境运行。比较点是 7 位配置返回输入范围错误，以及 8 位配置完成往返。实际错误文本交给标准库返回，不应在业务代码中依赖整段错误字符串作分支判断。

写入与结束错误都要保留

压缩函数先保留 Write 的错误，再调用 Close，最后合并两者。这样底层输出失败或流结束时的错误不会被忽略。任何一步失败都返回 nil 结果，避免调用方把压缩前缀保存为完整数据。示例采用局部 bytes.Buffer，所以放弃结果很直接。

如果目标改成已经对外可见的文件或网络连接，函数报错并不会撤回已经写出的部分。调用方需要自己的临时文件、事务式提交或消息失败标记。不要在同一个已失败的流上换一个 litWidth 接着写；修正配置后应重新开始一条完整压缩流。

把参数一致性写进数据约定

只把压缩端从 7 改成 8，而读取端仍然固定为 7，不是完整修复。对于自定义存储格式，应在消息元数据或版本化格式约定中明确位宽，让两端保持一致。这里示例固定使用 LSB，只为维持前后相同，不讨论位序的选型。

如果压缩流来自现成容器格式，不能为了让中文写入成功就擅自改动格式规定的参数。比如小字母表的数据可能本来是调色板索引，而不是文本字节。应先确认调用方究竟传入的是协议期望的数据，还是误把字符串塞进了另一种数据通道。

原始压缩字节也不是 UTF-8 文本。存储或传输时使用二进制字段、文件或明确的外层编码，避免把乱码显示当作压缩失败。中文是否恢复正确，可以在解压后先比较原始字节，再交给文本层处理。

扩展检查与相关问题

换成 rune 再压缩可以绕过限制吗？Writer 的参数仍然是 []byte。码点转换还需要另一套可逆字节表示，并不会自动扩大当前字面量范围。

8 位就一定比 7 位压缩率差吗？不能只凭位宽下结论。先满足输入与格式约束，再用真实数据比较大小；不应拿不合法配置的失败结果作性能对照。

可以直接用于任意 TIFF LZW 数据吗？标准库文档指出 TIFF 的 LZW 变体与本包实现不兼容。参数相同不等于格式兼容，需要对应格式的实现。

扩展自己的实验时可加入 ASCII、空输入和包含 0x80、0xff 的字节切片，分别观察输入范围与完成条件。实现阅读入口：https://go.dev/src/compress/lzw/writer.go。