Go crypto/sha3 New256 怎样复用哈希状态

批量计算 SHA3-256 时，真正需要复用的不是摘要字节，而是由 crypto/sha3.New256() 创建的哈希状态对象。正确顺序是：写入一条完整消息，调用 Sum 取出当前摘要，确认本条任务结束后调用 Reset，再处理下一条消息。

官方地址：https://pkg.go.dev/crypto/sha3

核心判断只有一句：Sum 负责追加当前结果，不会替你清空输入状态；要复用同一个对象，必须把 Reset 放在下一条消息写入之前，放进 sync.Pool 时还要在归还前再次清理。

先从“摘要越来越不对”这个信号开始排查

现场通常有两个表现：单条数据计算结果正确，改成循环后第二条开始全部不匹配；或者把哈希对象放进对象池后，偶发出现“同一输入在不同请求中得到不同摘要”。这类问题先不要怀疑 SHA3-256 算法本身，先看对象的生命周期。

New256 返回的是带内部状态的 *sha3.SHA3。连续调用 Write 会把字节继续加入当前消息；Sum(nil) 会把当前状态的摘要追加到一个切片并返回，但它不是“计算并清空”的快捷函数。因此，上一条输入还留在对象里时，下一条输入会被当成同一条更长消息的后缀。

把 Write、Sum、Reset 分成三个明确动作

复用代码最容易犯的错，是把“输出摘要”和“结束本轮”混成一个动作。可以把三个方法按下面的职责记住：

• Write：把当前消息的字节写入状态，返回写入字节数和错误。
• Sum：读取当前状态对应的摘要，并追加到传入切片；不会把对象恢复到初始状态。
• Reset：把对象恢复到刚创建时的初始状态，准备下一条独立消息。

最小封装应当把清理放在函数边界内。这样调用方不会因为忘记某个分支而把旧状态带到下一次任务：

package digest

import (
    "crypto/sha3"
    "fmt"
)

func SHA3256(data []byte) ([]byte, error) {
    h := sha3.New256()
    // New256 创建的是可写状态；本函数只处理一条独立消息。
    if _, err := h.Write(data); err != nil {
        return nil, fmt.Errorf("写入 SHA3-256 输入失败: %w", err)
    }
    // Sum 只读取当前状态并追加结果，不负责 Reset。
    digest := h.Sum(nil)
    // 显式 Reset 让这个函数的生命周期在返回前闭合，便于未来改成对象池实现。
    h.Reset()
    return digest, nil
}

对固定的 sha3.SHA3 实现，写入错误通常不会发生，但保留错误处理仍有两个价值：一是封装以后可以替换为其他 hash.Hash 实现，二是调用方能够看到完整的错误上下文，而不是把错误吞掉。

批量处理时，Reset 要放在下一次 Write 之前

如果一条记录一条记录地生成摘要，可以在每轮开始时先清理一次。这个位置比“上一轮结束时清理”更容易守住：即使上一轮中途返回、打日志或新增了分支，下一轮仍然会从干净状态开始。

package main

import (
    "crypto/sha3"
    "encoding/hex"
    "fmt"
)

func printDigests(records [][]byte) {
    h := sha3.New256()
    for index, record := range records {
        // 每轮先清空上条记录，避免多个输入被拼成一条消息。
        h.Reset()
        if _, err := h.Write(record); err != nil {
            // 当前实现通常返回 nil 错误；保留分支可以让替换实现安全失败。
            fmt.Printf("第 %d 条写入失败: %v\n", index, err)
            continue
        }
        // Sum(nil) 得到当前记录的 32 字节摘要，调用后状态仍然存在。
        digest := h.Sum(nil)
        fmt.Printf("第 %d 条: %s\n", index, hex.EncodeToString(digest))
    }
}

这里没有在 Sum 后立即假设对象已经空了。即便当前循环的下一步是 continue，下一轮开头的 Reset 仍然是最终防线。

放入 sync.Pool 时，同时守住取出和归还两道边界

当摘要任务频繁创建、对象短时间使用时，可以考虑用 sync.Pool 降低对象分配压力。但对象池只解决“对象暂存”，不会替你管理哈希状态。安全边界是：Get 后先 Reset，处理完并生成摘要后再次 Reset，最后才 Put。

package digest

import (
    "crypto/sha3"
    "fmt"
    "sync"
)

var sha3Pool = sync.Pool{
    New: func() any {
        // Pool 只负责提供对象，不把对象状态承诺给调用方。
        return sha3.New256()
    },
}

func PooledSHA3256(data []byte) ([]byte, error) {
    h := sha3Pool.Get().(*sha3.SHA3)
    // 即使上一个使用者按约定清理过，取出后再 Reset 也能封住脏状态风险。
    h.Reset()
    defer func() {
        // 归还前清理，禁止带着当前消息状态回到池中。
        h.Reset()
        sha3Pool.Put(h)
    }()

    if _, err := h.Write(data); err != nil {
        return nil, fmt.Errorf("写入池化 SHA3-256 输入失败: %w", err)
    }
    // 复制出结果后再结束本次使用；返回切片不依赖 h 的生命周期。
    return h.Sum(nil), nil
}

不要把同一个 *sha3.SHA3 同时交给多个 goroutine。它是可变状态，池化也不等于并发安全；每个并发任务应当独占一次 Get 到 Put 的生命周期。

出错时怎样回滚，怎样确认没有串状态

运行手册式的处理顺序可以固定成四步：

1. 记录输入记录的业务标识，不要把原始敏感内容写进日志。
2. 写入失败时立即返回错误，不把未完成的摘要写入结果表。
3. 无论成功还是失败，都执行 Reset；池化场景再决定是否归还对象。
4. 用两个已知输入做回归检查：同一输入多次结果相同，不同输入结果不应被前一条前缀污染。

func sameDigest(h *sha3.SHA3, left, right []byte) bool {
    // 每次比较都从初始状态开始，避免 left 的状态影响 right。
    h.Reset()
    _, _ = h.Write(left)
    leftDigest := h.Sum(nil)

    h.Reset()
    _, _ = h.Write(right)
    rightDigest := h.Sum(nil)

    // 这里用字符串仅作示例；真实鉴别场景应使用恒定时间比较。
    return string(leftDigest) == string(rightDigest)
}

上面的函数只用于说明复用边界，不是通用的密码学比较器。若摘要参与认证、签名或密钥相关判断，应使用合适的恒定时间比较方式，并单独设计协议，而不是把“复用哈希对象”当成安全方案。

最后留下这张复查清单

• 每条独立消息是否都在写入前执行了 Reset？
• 是否误把 Sum 当成了自动清理操作？
• 对象进入 sync.Pool 前是否再次 Reset？
• 是否让一个可变哈希对象跨 goroutine 共享？
• 写入失败时是否阻止了摘要落库，并保留了带上下文的错误？

如果只有一两条消息，直接创建 sha3.New256() 往往更清楚；只有在批量任务的分配成本确实值得优化时，才把对象复用和对象池引入。无论选择哪种写法，最重要的边界都不变：一条消息对应一次干净的哈希状态。

相关问题

为什么调用 Sum 后还要 Reset？因为 Sum 只把当前状态的摘要追加到返回切片，不会把内部状态恢复到初始值。

可以直接用 sha3.Sum256 吗？单条输入可以。它适合不需要保留可变哈希对象的场景；本文关注的是批量流程中复用状态对象的边界。

sync.Pool 一定能提升性能吗？不一定。它需要通过基准测试比较分配、GC 和任务吞吐，不能只凭“少创建对象”就下结论。