hex.DecodeString 解码失败主因是输入格式错误：需偶数长度、仅含0-9a-fA-F字符，空串或奇数长须提前校验，含空格/“0x”需清洗；高频编码应复用缓冲区避免GC压力，UTF-8字符串编码得字节而非码点，哈希结果转hex须校验长度与大小写一致性。
hex.DecodeString 解码失败：常见错误和输入校验
解码失败几乎全是输入格式问题，不是函数本身有 bug。hex.DecodeString 要求输入必须是偶数长度、只含十六进制字符（0-9a-fA-F），否则直接 panic 或返回 encoding/hex: invalid byte 错误。
- 空字符串或 nil 输入会 panic，务必先判空：
if s == "" { return nil, errors.New("empty hex string") } - 奇数长度字符串（如
"a"或"ff1"）一定失败，可用len(s)%2 != 0提前拦截 - 含空格、换行、前缀
"0x"的字符串需先清洗：strings.ReplaceAll(strings.ToLower(s), "0x", "")，再 trim 空白 - 注意大小写：虽然
hex.DecodeString支持大小写混合，但某些外部协议（如 Ethereum 地址）要求全小写校验，别只解码不验证语义
hex.EncodeToString 性能陷阱：别在循环里反复调用
hex.EncodeToString 内部每次都会 new 一个 []byte，如果在高频路径（如日志、序列化循环体）中对小字节切片反复调用，GC 压力明显上升。
- 对固定长度数据（如 16 字节 UUID、32 字节哈希），优先复用
make([]byte, hex.EncodedLen(n))缓冲区，配合hex.Encode使用 - 示例：
dst := make([]byte, hex.EncodedLen(len(src))); hex.Encode(dst, src)，比hex.EncodeToString(src)少一次内存分配 - 如果只是临时调试打印，用
fmt.Printf("%x", data)更轻量，不依赖encoding/hex
处理非 ASCII 字符串时的编码混淆
Go 的 string 是 UTF-8 编码的字节序列，不是“字符数组”。直接对中文、emoji 字符串调用 hex.EncodeToString 得到的是 UTF-8 字节的十六进制表示，不是 Unicode 码点。
- 例如：
hex.EncodeToString([]byte("你好"))输出"e4bda0e5a5bd"（UTF-8 字节），不是"4f60597d"（Unicode 码点） - 若协议要求按 Unicode 码点编码（极少见），需先转
rune切片再处理，但绝大多数场景（HTTP header、crypto hash、binary protocol）都应操作原始字节 - 从 hex 还原字符串时，只要原始字节是合法 UTF-8，
string(decoded)就安全；否则会得到乱码，这不是 hex 包的问题，而是源头数据本就不该被当字符串解释
与 crypto/sha256 等哈希结果配合的典型用法
哈希函数返回的是 []byte，直接打印是 [98 102 ...]，人类不可读。转 hex 是标准做法，但要注意长度和大小写一致性。
立即学习“go语言免费学习笔记（深入）”；
- SHA256 固定输出 32 字节 → hex 编码后一定是 64 字符，可作为校验：
if len(hexStr) != 64 { return err } - 避免混用大小写：
hex.EncodeToString输出小写，但有些系统（如 Git commit ID）习惯小写，而某些硬件模块返回大写，比较前统一strings.ToLower或strings.ToUpper - 不要用
fmt.Sprintf("%x", hash.Sum(nil))替代hex.EncodeToString—— 前者对[]byte安全，但对hash.Hash接口类型可能触发额外拷贝
