hex.DecodeString 会 panic 是因输入含非十六进制字符（如空格、'g'）或长度为奇数；需先 trim、校验长度、过滤非法字符再解码，不可依赖 recover。
为什么 hex.DecodeString 会 panic: illegal hex character？
因为输入字符串含非十六进制字符（比如空格、换行、字母 G 或小写 g），而 hex.DecodeString 默认只接受严格格式：偶数长度、全为 0-9a-fA-F。
常见错误现象：panic: encoding/hex: invalid byte: U+0020 ' '（空格）、invalid byte: U+0067 'g'（非法字母）。
- 调试时别直接用
fmt.Println看原始字符串——它会隐藏不可见字符，改用fmt.Printf("%q", s)查看真实字节 - 若来源不可控（如用户输入、HTTP 参数），先用
strings.TrimSpace去首尾空白，再用正则或strings.Map过滤掉非 hex 字符（但注意：这会改变语义，仅限调试场景） -
hex.DecodeString不处理大小写混合问题——它本身支持大小写，但必须是合法字符；真正出错的往往是误把"0x1a"这类带前缀的字符串直接传入
如何安全地从字符串还原 []byte 而不 panic？
别依赖 recover，而是提前校验 + 标准化。Go 标准库没提供“宽松解码”，得自己兜底。
使用场景：日志里复制的 hex dump、调试时手写的测试数据、API 返回的 hex 编码 payload。
立即学习“go语言免费学习笔记（深入）”；
- 检查长度是否为偶数：
len(s)%2 != 0→ 直接报错或补零（补零需明确业务意图） - 用
hex.DecodeString前先做白名单过滤：strings.Map(func(r rune) rune { if ('0' - 更稳妥的做法：用
hex.Decode配合bytes.NewReader，它返回 error 而非 panic，便于错误分类处理
hex.EncodeToString 和 hex.Dump 的输出差异在哪？
hex.EncodeToString 输出纯 hex 字符串（如 "48656c6c6f"），hex.Dump 输出带偏移、ASCII 预览的调试格式（如 "00000000 48 65 6c 6c 6f |Hello|\n"）。
性能影响：两者都遍历字节，但 hex.Dump 多做 ASCII 映射和格式化，内存开销略高，**仅用于调试，切勿在 hot path 使用**。
- 日志中想快速定位二进制内容？用
hex.Dump—— 它自动换行、对齐，肉眼友好 - 需要存数据库或传网络？用
hex.EncodeToString—— 纯字符串，无额外空格/换行，体积最小 -
hex.Dump对空字节（\x00）显示为.，而EncodeToString忠实输出"00"，这点在比对原始数据时容易忽略
调试 Go 二进制数据时，为什么 hex 编码比 base64 更常被选中？
因为 hex 每字节转 2 字符、映射确定、无填充、无换行、可读性折中——适合人工扫一眼确认字段边界或魔数。
兼容性影响：所有语言都有标准 hex 编解码，但注意大小写约定——Go 默认输出小写，Python binascii.hexlify 也是小写，但某些嵌入式协议可能要求大写，此时得用 strings.ToUpper(hex.EncodeToString(b))。
- 查 TCP 包头？Wireshark 默认显示 hex，和
hex.Dump对齐度高 - 验证加密输出（如
sha256.Sum256）？直接fmt.Printf("%x", sum)比先转[]byte再 encode 更轻量 - 别把
hex.EncodeToString当序列化用——它不携带类型或长度信息，只是 raw bytes 的文本表示
hex 编解码本身很简单，但真正难的是搞清你手上的那串字符串到底是不是“干净”的 hex——中间有没有人手改过、有没有编辑器悄悄加了 BOM、有没有 JSON unmarshal 时被多解了一层。这些细节不打日志、不看 %q，很容易卡一小时。
