Go 1.25 hash.XOF 怎么选固定摘要与可扩展输出：SHAKE 读长和接口边界

做文件指纹、协议摘要时，固定 32 字节的 SHA-256 很顺手；但密钥派生、可变长度标签或分段输出，往往需要“写入一次，按需读出任意长度”。Go 1.25 的 hash.XOF 就是为这个边界准备的接口，SHAKE 实现可以在同一份输入上持续读取结果。

需要固定长度、可直接比较的摘要时选 hash.Hash；需要可变长度输出时选 hash.XOF，但必须把输出长度写进协议或测试约定，不能让调用方随意猜。

先按输出契约区分两类接口

选型不要从“SHAKE 看起来更先进”开始，而要先看下游字段是不是定长。缓存键、数据库列、签名待签名串通常已经规定了字节数，这时固定输出的 hash.Hash 更容易审计。相反，如果协议规定“读取 64 字节上下文扩展值”，或者派生材料分成多个区段，hash.XOF 才能避免先猜一个最大长度再截断。

func fixedDigest(data []byte) []byte {
    h := sha256.New()
    _, _ = h.Write(data)
    return h.Sum(nil)
}

上图只绑定本节的三个真实节点：hash.Hash 代表固定摘要接口，hash.XOF 代表可扩展输出接口，Read 是 XOF 的取数入口。它们不是两种可以随意混用的返回值类型。

固定摘要和 SHAKE 的最小写法

固定长度：调用 Sum 得到完整结果

hash.Hash 的典型流程是不断 Write，最后调用 Sum(nil)。摘要长度由具体实现决定，调用方不需要维护游标。

func digest256(data []byte) []byte {
    h := sha256.New()
    _, _ = h.Write(data)
    return h.Sum(nil)
}

可变长度：Read 是输出游标

SHAKE 属于 XOF，构造后先写输入，再把输出读入调用方提供的切片。这里用 sha3.NewShake256，读取 32 字节和 64 字节只是输出契约不同，输入不变。

func shakeOutput(data []byte, n int) ([]byte, error) {
    if n 

第二张图对应这段代码的真实路径：Write 把输入送进 XOF，Read 消费输出位置，Reset 才能让同一个对象回到可重新写入的初始状态。

Read、长度和复用的边界

io.ReadFull 适合“必须拿够 n 字节”的场景；如果协议允许分段消费，也可以直接多次调用 Read。关键是把长度写成接口契约，例如 32 字节用于短标签、64 字节用于扩展材料，而不是在不同调用点各自决定。

XOF 的输出有位置概念。读过 32 字节后再读 32 字节，拿到的是后续字节，不是前 32 字节的重复。需要从头计算另一份输入时，先调用 Reset，再重新 Write；不要把已读对象当成普通的无状态函数。

什么时候不该换成 hash.XOF

如果数据模型只接受固定宽度字段，或者需要直接使用某个算法规定的摘要长度，hash.Hash 更清楚。把 XOF 输出截成固定长度并不会自动获得新的安全性质，还会让审计者追问截断长度、编码方式和版本兼容。

另外，XOF 并不替代密码协议设计。密钥派生、随机数和签名输入仍要遵循对应标准，不能因为可以读任意长度，就把用户可控字符串直接当作密钥。

一张表定下接口选择

常见问题与核对方式

hash.XOF 能不能直接调用 Sum？

不要把 XOF 当成固定摘要使用。它的核心输出入口是 Read，长度由读取缓冲区和协议约定共同决定。

为什么同样的输入读取 32 字节和 64 字节不一样？

64 字节结果包含前 32 字节以及后续扩展部分。两种长度应分别写入测试向量或协议说明，避免下游误把它们当成同一个字段。

Reset 后还需要重新 Write 吗？

需要。Reset 只清回初始状态，不会替你恢复上一份输入。

把长度当成接口的一部分

固定摘要和可扩展输出的分界，其实是“谁负责定义结果长度”。让算法对象负责固定长度，就选 hash.Hash；让协议明确长度并由调用方读取，就选 hash.XOF。无论哪种写法，给 Write、Read、Reset 配套小测试，比只检查一组十六进制字符串更能抓住复用和分段读取的错误。