必须用argon2.idkey而非argon2.key，因其自动安全生成16字节随机盐并返回标准编码字符串，避免手动控盐导致的盐复用；参数推荐m=65536、t=3、p=4；验证时应直接用comparehashandpassword。
直接用 argon2.IDKey，别碰 argon2.Key —— 后者不带盐自动管理，手动控盐极易复用或写死，一招破防。
为什么必须用 argon2.IDKey 而不是 argon2.Key
argon2.Key 要求你显式传入 salt，但 Go 标准库没提供安全生成盐的封装函数。常见错误包括：
- 用固定字节数组，比如
[]byte("mysalt123")，所有用户哈希共用一个盐 - 复用同一片内存（如全局
var salt = make([]byte, 16)），每次调用都覆盖重用 - 忘记调用
crypto/rand.Read，导致盐为全零或未初始化内存
argon2.IDKey 内部自动调用 crypto/rand.Read 生成 16 字节随机盐，并把盐、参数、哈希拼成标准格式字符串（如 $argon2id$v=19$m=65536,t=3,p=4$...），天然防盐复用，可直接入库。
argon2.IDKey 的三个参数怎么设才不翻车
参数不是越大越安全，得看你的微服务部署环境和 SLA 要求。Web 登录类接口建议起步值：
-
m=65536：对应约 64 MiB 内存占用；低于32768（32 MiB）易被 GPU/ASIC 加速破解 -
t=3：在普通 CPU 上耗时约 200–400ms；设为1太快，8+在高并发下易触发超时 -
p=4：设为服务器逻辑核数（如 4 或 8），但不要超过物理核心数，否则线程调度反拖慢响应
注意：argon2.IDKey 第四个参数是输出密钥长度，通常设 32（即 256 位哈希），别设太小（如 16）—— OWASP 明确建议 ≥ 256 位。
验证密码时别自己解析哈希字符串
从数据库读出的完整哈希字符串（如 $argon2id$v=19$m=65536,t=3,p=4$...）必须直接传给 argon2.CompareHashAndPassword：
- 它会自动提取盐、版本、参数并重算比对，无需你
strings.Split或base64.Decode - 内部使用恒定时间比较，防时序攻击；自己写
bytes.Equal就等于放弃这层防护 - 若哈希字符串被截断（比如字段长度限制为 64）、或经 URL/JSON 传输时
+被误作空格，CompareHashAndPassword会返回error，此时应检查入库前的长度（典型输出在 100–120 字节）
常见坑：ORM 自动 trim 空格、MySQL VARCHAR(64) 存不下、PostgreSQL TEXT 字段被意外转义。
Argon2 在 Go 微服务里不是“开箱即用”的真实代价
golang.org/x/crypto/argon2 只暴露底层原语，不像 bcrypt 那样有 GenerateFromPassword 这种一步到位函数。这意味着：
- 你得自己确保每次调用
argon2.IDKey都是全新上下文，不能共享salt或复用参数变量 - 哈希字符串含
/和+，走 HTTP header 或 JWT payload 时必须做 URL-safe base64 编码，否则可能被中间件破坏 - 未来升级参数（比如把
m从 65536 提到 131072），旧哈希仍能验证，但新注册用户要用新参数 —— 你需要在哈希字符串里识别版本，或额外存一个hash_version字段
最易被忽略的一点：微服务多实例部署时，别在 init 函数里预热或缓存参数对象，argon2.IDKey 不是线程安全的封装，每次调用都该是干净的、独立的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
