hex.EncodeToString 返回空字符串最常见原因是传入 nil 或零长度切片；DecodeString 报“invalid byte”多因输入长度非偶数、含非十六进制字符或前缀未清除。
hex.EncodeToString 为什么返回空字符串？
最常见原因是传入了 nil 或零长度切片。Go 的 hex.EncodeToString 不会 panic，但对 []byte(nil) 或 []byte{} 都返回空字符串，容易误判为“编码失败”。
- 检查原始数据是否非空：
if len(data) == 0要提前处理，别直接塞给hex.EncodeToString - 注意字符串转字节时的隐式截断：比如
[]byte("hello\x00world")是合法的，但若你从 C 交互或二进制协议中读取，\x00后内容可能被忽略——这不是 hex 的问题，是上游数据源的问题 - 调试时用
fmt.Printf("%q", data)看原始字节，比直接打印string(data)更可靠
DecodeString 报错 encoding/hex: invalid byte？
这个错误几乎全是输入格式不合规导致的：长度不是偶数、含非十六进制字符（如空格、换行、大小写混用但未标准化）、或者用了全角字符。
- 先用
strings.TrimSpace去首尾空白，再检查长度：if len(s)%2 != 0就不用继续 decode 了 - 不要假设输入一定小写；
hex.DecodeString接受大小写混合，但某些旧工具输出可能带前缀0x或0X，得手动去掉：strings.TrimPrefix(strings.TrimPrefix(s, "0x"), "0X") - 如果来源不可控（比如 HTTP query 参数），建议用
hex.DecodeString(strings.Map(func(r rune) rune { if r >= 'A' && r 统一小写再解码，避免大小写判断逻辑散落各处
性能敏感场景下，该用 EncodeToString 还是 Encode？
前者分配新字符串，后者复用目标切片。高频或大数据量时，hex.Encode 配合预分配切片能减少 GC 压力。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
hex.EncodeToString(data)简洁安全，适合日志、调试、低频 API 返回 - 批量处理时，用
dst := make([]byte, hex.EncodedLen(len(data)))预分配，再调用hex.Encode(dst, data)，避免每次分配 - 注意
hex.EncodedLen(n)返回的是编码后字节数（2×n），不是字符串长度——它和len(string(dst))相等，但类型不同
和 JavaScript 的 atob/btoa 或 Python 的 binascii.hexlify 行为一致吗？
基本一致，但细节上要注意：Go 的 hex 包不处理编码/解码中的填充、分隔符或大小写标准化，而 JS/Python 工具链有时会自动做这些。
立即学习“go语言免费学习笔记（深入）”；
- JS 的
Buffer.from("48656c6c6f", "hex").toString()和 Go 的hex.DecodeString+string()结果相同，但 JS 若传入奇数长度会报错，Go 则直接返回 error - Python 的
binascii.hexlify(b"Hello")默认输出小写，Go 的EncodeToString也是小写，没问题；但若 Python 用了codecs.encode(b"Hello", "hex")，行为一致 - 跨语言调试时，优先用
xxd -p或echo -n "Hello" | xxd -p生成标准 hex 字符串作基准，比靠记忆更稳
hex 编解码本身很薄，真正容易出问题的地方永远在边界：数据来源是否可信、长度是否对齐、空字节是否被截断、大小写是否混杂。别把问题想成“Go 的 hex 有 bug”，先查三遍输入。
