Go encoding/hex.Decoder 怎样处理不完整输入

如果十六进制内容可能分多次到达，优先使用 hex.NewDecoder 包装原始 io.Reader，再像读取普通字节流一样读取解码结果。它不会要求每次传入的数据块都恰好成对；真正的边界发生在整个输入结束时：正常的偶数个十六进制字符返回 io.EOF，最后缺半个字节则返回 io.ErrUnexpectedEOF，遇到非十六进制字符则返回对应错误。

核心判断是：块边界可以被拆开，但十六进制字符总数必须在流结束前闭合。不要因为某一次 Read 只拿到半个字符就立刻判定输入损坏。

先分清三种解码入口

hex.Decode 和 hex.DecodeString 面向已经完整落在内存中的输入。它们要求输入只包含十六进制字符，并且长度为偶数；奇数长度通常对应 hex.ErrLength。hex.NewDecoder 返回一个新的 io.Reader，适合文件、网络响应或其他仍在产生数据的来源。

分块读取时不要把块边界当成数据边界

下面的示例把解码器当作普通 Reader 使用。调用方只关心返回的字节数和错误；底层解码器负责保存跨块的半字节状态。示例中的输入被人为拆成多个块，是为了说明边界关系，并不代表必须由业务代码手动拼接。

package main

import (
    "encoding/hex"
    "fmt"
    "io"
    "strings"
)

func main() {
    // strings.Reader 模拟网络或文件分块来源；块边界不等于十六进制字节边界。
    source := strings.NewReader("48656c6c6f")
    decoded := hex.NewDecoder(source)
    buf := make([]byte, 3)

    for {
        n, err := decoded.Read(buf)
        if n > 0 {
            // 先消费本次已经成功解码的字节，再判断 err。
            fmt.Printf("%q", buf[:n])
        }
        if err == io.EOF {
            // 偶数长度输入完整收尾。
            break
        }
        if err != nil {
            // 非法字符或不完整收尾都不能当作正常结束。
            panic(err)
        }
    }
}

判断顺序很重要：Read 可能同时返回 n > 0 和一个错误，所以应先处理已经拿到的字节，再处理错误。对于普通的完整流，最终错误是 io.EOF；如果业务要把结果交给后续解析器，应在收到 EOF 后再决定是否提交完整消息。

不完整输入与非法字符怎么区分

例如 486 只有三个十六进制字符，前两个字符可以组成一个字节，但最后的 6 缺少配对字符。流式 Decoder 会把它视为不完整的输入，结束时返回 io.ErrUnexpectedEOF。这和 0g 这种含有非法字符的输入不同，后者应按非法字节错误处理。

• 收到一部分字节后报错：保留已经读取的字节，但不要把整条消息标记为成功。
• io.ErrUnexpectedEOF：通常表示上游提前结束、传输被截断或协议长度不匹配，适合记录为不完整数据。
• 非法字符错误：应拒绝当前消息；不要通过删除未知字符来“修复”，否则字节位置会发生变化。

收尾检查清单

把 NewDecoder 放进生产代码前，可以按下面的顺序检查：

1. 输入是持续的 Reader，还是已经完整存在内存里的字符串？完整字符串优先考虑 DecodeString。
2. 业务是否允许分块？允许的话，不要依赖一次 Read 恰好读出一对字符。
3. 是否在 n > 0 时先消费数据？这是所有 Reader 都应遵守的规则。
4. 是否把 io.ErrUnexpectedEOF 与正常 io.EOF 分开记录？两者代表完全不同的输入状态。
5. 上游是否有长度、校验和或消息边界？若有，应同时检查这些协议条件，不能只依赖十六进制解码成功。

常见问题

为什么不能看到一次 Read 返回少量数据就报错？

Reader 允许返回小于缓冲区容量的数据，底层输入可能只是暂时没有更多内容。只有读到结束并确认剩余半字节时，才能判断是否为不完整十六进制输入。

奇数长度一定要补 0 吗？

不一定。补 0 会改变原始数据的含义，只有协议明确规定补位方向和规则时才可以做。否则应保留 io.ErrUnexpectedEOF，让上游修复截断或重新发送。