直接用 crc32.checksum 读大文件会 oom 或 panic，必须用 crc32.new 配合 io.copy 流式计算；校验值不一致主因是字节序、表类型、初始值或终值异或未对齐。
直接用 crc32.Checksum 读整个文件会 panic 或 OOM，必须流式计算；校验值对不上，90% 是字节序、表类型或初始值/异或值不一致导致的。
用 crc32.New 流式计算大文件 CRC32
这是唯一安全处理 GB 级文件的方式。核心是避免把文件全 load 进内存，而是边读边喂给哈希器。
-
crc32.New必须传*crc32.Table，别手写，直接用crc32.MakeTable(crc32.IEEE)或更常用的crc32.IEEETable - 打开文件后，用
io.Copy(h, f)把*os.File流进hash.Hash32实例（它实现了io.Writer） - 调
h.Sum32()拿结果——比Sum(nil)[len-4:]更直接、不易错 - 复用实例前必须调
h.Reset()，否则结果是累加的
table := crc32.IEEETable
h := crc32.New(table)
f, _ := os.Open("bigfile.dat")
defer f.Close()
io.Copy(h, f)
crc := h.Sum32() // uint32 类型，无需手动转字节
用 crc32.Checksum 快速校验小数据（字符串、配置片段）
适合内存可控场景，比如校验 JSON 字段、HTTP body 片段、环境变量值等。省去流式 setup，但绝不适用于文件全量读取。
- 输入必须是
[]byte：中文字符串要先转[]byte(s)，不能直接传 string - 第二个参数必须是非 nil 表，
crc32.IEEETable最通用，和cksum、zlib.crc32()默认行为一致 - 传
nil表会 panic: "invalid table" - 返回值是
uint32，可直接比较或格式化为 8 位 hex：fmt.Printf("%08x", crc)
s := "hello世界"
crc := crc32.Checksum([]byte(s), crc32.IEEETable)
fmt.Printf("%08x", crc) // 输出如：d52b6c7a
CRC32 校验失败？先查这三件事
协议对接、嵌入式通信、跨语言比对时最容易卡在这几个点，不是代码写错了，而是约定没对齐。
-
字节序误判：Go 的
Sum32()返回原生uint32，打印%x在小端机器上是低位在前；多数协议文档按大端写（如0xd52b6c7a实际对应内存中7a 6c 2b d5）。比对前统一用binary.BigEndian.Uint32(sum[:])或直接用 hex 字符串比 -
表类型不匹配：
crc32.IEEETable是默认，但某些设备用crc32.KoopmanTable，甚至自定义多项式。表错一个 bit，结果全错 -
初始值或终值异或未处理：SL651、ISO-HDLC 等标准要求初始值为
0xffffffff或最终结果^ 0xffffffff。Go 标准库不做这些，得手动 wrap：crc32.Checksum(data, table) ^ 0xffffffff
空文件、小文件、并发场景的注意事项
这些边界情况容易被忽略，但线上出问题往往就在这里。
- 空文件的 CRC32 是
0x00000000，流式和Checksum方式结果一致，无需特殊判断 - 不要在多个 goroutine 里共用同一个
hash.Hash32实例 ——Write不是并发安全的，会竞态 - 如果要做分块上传校验，每块单独算 CRC 后再拼接，别试图用一个哈希器跨块累积（除非你明确控制 Reset 时机）
- 纯校验场景下，CRC32 足够快；但若需防篡改（而不仅是检错），请换
crypto/sha256—— CRC32 可被轻易逆向构造碰撞
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
