Go 标准库中的 fmt.Sscanf 并不支持通过子切片指针直接写入底层数组；它会为切片分配全新的内存。正确的做法是先将十六进制串解析为独立临时字节切片，再合并或手动复制回目标底层数组。

在 Go 语言中利用 fmt.Sscanf 处理十六进制字符串时，许多开发者会直觉地使用子切片来接收解析结果，认为子切片共享同一块底层数组理应在原地写入。但实际情况恰恰相反：Sscanf 接收 *[]byte 参数后，内部会无条件为切片重新分配底层内存，而不是向原有地址写入。你传递的子切片经过解析后，其 Data 指针已经与原来的数组彻底分离。

看一个具体例子就能明白。以下的代码看似无懈可击，实际上却无法工作：

func Parse(data string) ([]byte, error) {
    bs := make([]byte, 6)
    a := bs[0:2] // 指向 bs[0:2]
    b := bs[2:4] // 指向 bs[2:4]
    c := bs[4:6] // 指向 bs[4:6]
    _, err := fmt.Sscanf(data, "%4x-%4x-%4x", &a, &b, &c) // ❌ a/b/c 被重分配！
    return bs, err // bs 仍是 [0 0 0 0 0 0]
}

问题根源在哪里？Sscanf 对切片指针的语义是“分配并填充”，而非“就地写入”。换句话说，你把它带到一个空房子里，它却另建了一座新房，然后把旧房地址直接丢弃。

推荐解决方案：改用固定长度字节数组 + 显式转换

如何才能避开这个陷阱？最简洁的方法是放弃切片，改为使用固定长度数组。Sscanf 对 *[N]byte 类型十分友好，它能够识别数组大小并逐字节写入——而 %4x 正好对应 2 字节，与 [2]byte 的尺寸完美匹配。请看改造后的代码：

func Parse(data string) ([]byte, error) {
    var a, b, c [2]byte // 声明固定长度数组（非切片！）
    n, err := fmt.Sscanf(data, "%4x-%4x-%4x", &a, &b, &c)
    if err != nil || n != 3 {
        return nil, fmt.Errorf("parse failed: %w", err)
    }
    // 将三个 [2]byte 合并为 []byte（共享底层数组，零拷贝）
    result := append(a[:], b[:]...)
    result = append(result, c[:]...)
    return result, nil
}

调用 Parse("00ff-ff00-00ff") 会正确返回 [0 255 255 0 0 255]。这背后的关键在于数组指针的语义：&a 中的 a 是 [2]byte 类型，Sscanf 能够感知其固定大小，直接将读取的字节写入该数组。

注意事项

• &a 中 a 是固定长度数组，Sscanf 会按照 %4x（对应 2 字节）逐字节填充，不存在歧义。
• 如果坚持使用切片也不是不可以，但必须接受“它一定会重新分配”的事实，然后手动将结果复制回原数组：

  _, err := fmt.Sscanf(data, "%4x-%4x-%4x", &a, &b, &c)
  if err != nil { return nil, err }
  copy(bs[0:], a) // 显式复制回原数组
  copy(bs[2:], b)
  copy(bs[4:], c)

• 格式字符串必须严格匹配：%4x 表示 4 位十六进制数字（即 2 字节）。输入 "00ff" 合法，但 "ff" 位数不足会导致解析失败。

总而言之，Sscanf 对切片指针并没有“就地写入”的语义，其本质就是“分配并填充”。优先选用固定长度数组（[N]byte）配合 &array，既能保证安全，又让代码清晰易懂。若需要动态长度，则改用 strconv.ParseUint 配合手动字节拆分，行为完全可控，无任何意外。