Go subtle.XORBytes 长度不一致为什么会 panic

在 Go 里调用 crypto/subtle.XORBytes 时，最容易误解的一点是：两个输入切片长度不同，并不代表函数会像普通字节截断工具一样“取较短的一段然后正常返回”。官方文档确实规定写入数量是 n = min(len(x), len(y))，但它同时要求两个输入切片长度相同；长度不一致时，调用可能直接 panic。另一个独立边界是 dst 的长度必须至少能容纳 n 个字节。

XORBytes 的排错顺序可以固定为：先检查 len(x) == len(y)，再保证 len(dst) >= n，最后确认切片没有不允许的部分重叠。不要把返回值里的较短长度理解成“输入长度不一致也安全”。

• 写入数量：n 是 len(x) 与 len(y) 的较小值。
• 输入约束：x 和 y 长度不一致时，不能按普通截断逻辑使用。
• 目标约束：dst 长度小于 n 时会 panic，并且不会写入 dst。
• 内存约束：dst 与输入可以精确重叠或完全不重叠，其他重叠关系不要依赖。

先分清两个容易混淆的长度问题

假设 x 有 16 个字节，y 有 16 个字节，函数需要写入的数量就是 16，此时 dst 至少要有 16 个字节的长度。若 dst 只有 8 个字节，问题在目标缓冲区，不在两个输入切片的长度。

如果 x 有 16 个字节、y 有 12 个字节，从文档表面看 n 会是 12；但这不等于“把前 12 个字节当作完整结果”就是可靠的业务语义。输入通常代表同一段数据的两个版本，长度不一致往往意味着上游拼接、切片范围或协议边界出了问题。调用前主动检查，才能把错误留在更接近源头的位置。

为什么输入长度不一致时会 panic

crypto/subtle 面向的是需要谨慎使用的密码学辅助操作。XOR 的字节级运算本身很简单，真正容易出错的是调用者是否清楚每个字节的对应关系。如果一边的数据比另一边短，继续把两者当成同一份数据的对应位置，可能会把截断、补齐和协议错误混为一谈。

因此，看到“长度不一致”时，不要先通过补零、直接截断或忽略 panic 来让程序继续跑。先回到生成 x 和 y 的代码，确认它们是否应该代表同样长度的内容；如果业务确实允许不同长度，也要在调用 XORBytes 之前明确选择截断或补齐策略，并把结果长度写进接口约定。

安全调用的 Go 写法

下面这个小函数把长度检查放在 XOR 之前，并为结果创建与输入相同长度的独立缓冲区。这样，输入长度不一致会返回普通错误，目标缓冲区不足也不会成为隐藏的运行时 panic。

package main

import (
    "crypto/subtle"
    "errors"
    "fmt"
)

func xorEqualLength(x, y []byte) ([]byte, error) {
    // 两个输入代表同一组位置时，先拒绝长度不一致。
    if len(x) != len(y) {
        return nil, errors.New("xor inputs must have equal length")
    }

    // dst 的长度必须至少覆盖 n；同长度输入时 n 就是 len(x)。
    dst := make([]byte, len(x))
    n := subtle.XORBytes(dst, x, y)
    if n != len(dst) {
        return nil, fmt.Errorf("unexpected XOR length: got %d, want %d", n, len(dst))
    }
    return dst, nil
}

这里的第二个判断不是为了掩盖 API 行为，而是给封装层留下一道防线：如果后续代码改变了输入准备方式，返回值与预期长度不一致时可以尽早暴露。对固定长度协议、摘要缓冲区或认证数据，这种显式约束通常比静默丢弃尾部字节更容易维护。

dst 长度不足是另一条 panic 边界

即使 x 和 y 长度相等，dst 仍可能准备错误。需要注意的是 Go 切片的“长度”和“容量”不是一回事：make([]byte, 0, 32) 的容量虽然是 32，但长度是 0，不能直接作为一个可写入 32 字节的 dst 传给 XORBytes。如果要让函数写入 32 个字节，应使用 make([]byte, 32)，或把已有缓冲区切到足够的长度。

buf := make([]byte, 32)

// 这里的 len(buf) 是 32，足以容纳 32 个写入字节。
n := subtle.XORBytes(buf, x, y)
_ = n

调用前可以用 n := min(len(x), len(y)) 的逻辑计算目标需求，但在已经确认输入长度相等的封装中，直接按输入长度分配往往更清楚。不要只看 cap(dst) 就认为调用安全，API 判断的是目标切片的长度。

切片重叠也要保持简单

官方文档允许 dst 与 x 或 y 精确重叠，也允许完全不重叠；除此之外的部分重叠可能触发 panic。实际代码里，最不容易误读的方案是准备一个新的输出切片，让 dst 与两个输入完全分离。

如果为了减少一次分配而复用底层数组，必须能明确证明是精确重叠，而不是两个切片共享数组但起始位置或范围不同。只有在这个内存关系已经由数据结构保证时才考虑复用，否则独立的 dst 更便于审查，也更不容易在重构后失效。

常见问题 FAQ

len(x) 和 len(y) 不一样时，能不能直接取较短结果？

不要直接这样做。文档定义了写入数量的计算方式，但输入长度不一致仍是需要先处理的边界。除非业务明确规定要截断，并且在调用前已经完成截断，否则应返回错误或修正上游数据。

dst 只设置了足够的 cap，为什么仍然 panic？

XORBytes 写入的是切片长度范围，不是只看容量。make([]byte, 0, n) 的长度为 0；应创建长度为 n 的切片，或把已有切片切到长度至少为 n。

返回值 n 应该怎么使用？

n 是实际写入的字节数。对输入长度相等且 dst 足够长的封装，通常可以把它和预期长度比较，用于发现调用条件被意外改变；不要把它当作输入不一致时的自动修复信号。

可以复用 x 作为 dst 吗？

只有在它与输出是精确重叠关系时才符合文档允许的范围。若只是部分重叠，行为可能 panic。除非内存关系非常明确，优先使用独立的输出切片。

排查 subtle.XORBytes 时，可以记住一句话：较短长度是写入数量的计算结果，不是对不一致输入的许可。先让 x 与 y 满足业务上的长度约定，再让 dst 满足写入长度要求，最后才讨论是否需要复用底层数组。