PBKDF2.Key()参数顺序固定为：密码字节切片、盐值字节切片、迭代次数、目标密钥长度、哈希构造函数；必须严格匹配Go标准库，错位将导致逻辑错误，如将dkLen误作iter使防护失效。
pbkdf2.Key() 参数顺序和类型必须严格匹配
Go 标准库 crypto/pbkdf2.Key() 的参数顺序是固定的：密码字节切片、盐值字节切片、迭代次数、目标密钥长度、哈希构造函数。任何错位（比如把 iter 和 dkLen 位置互换）都会导致编译通过但逻辑错误——生成的密钥长度不对或迭代被忽略。
常见错误现象：pbkdf2.Key(pwd, salt, 32, 100000, sha256.New) 看似像“32字节+10万次”，实则把 dkLen=32 当成了 iter，真正迭代只有 32 次，完全失去防护意义。
- 密码必须是
[]byte，不能直接传string（虽然 Go 允许隐式转换，但语义易混淆；显式写[]byte(pwd)更安全） - 盐值必须是随机生成的
[]byte，长度建议 ≥16 字节；用make([]byte, 16)+rand.Read()，别用时间戳或固定字符串 - 哈希函数必须传构造器，如
sha256.New（无括号），不是sha256.New()（后者是实例，类型不匹配）
迭代次数设为 100000 是当前安全底线
低于 100000 次迭代在现代 CPU（如 Intel i7/i9 或 AWS c6i 实例）上耗时不足 1ms，攻击者每秒可尝试数万次密码；而 100000 次能让单次派生稳定在 5–15ms，兼顾安全与响应体验。
不要硬编码 1000 或 10000 —— 这些数值在 2021 年就已过时，2026 年实测在主流服务器上仅需微秒级即可完成，形同虚设。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 生产环境建议从
PBKDF2Iterations = 100000起步，每 2 年评估是否提升（例如 2028 年可调至 200000） - 避免动态计算迭代次数（如按 CPU 频率缩放），会引入时序侧信道风险且增加验证复杂度
- 若需兼容旧系统迁移，可在数据库中额外存一个
pbkdf2_iter字段，验证时按实际存储值执行，而非统一降级
盐值必须独立存储且每次注册都重生成
盐值不是“加点随机数”而已，它是防止彩虹表复用的核心。同一个用户重复注册、同一密码在不同账户使用，盐值都必须完全不同。
典型错误：全局复用一个盐（如常量 var globalSalt = []byte("fix-salt-2026")），或从用户名派生盐（sha256.Sum256([]byte(username))），这会让相同密码仍生成相同密钥。
- 生成方式必须用
crypto/rand.Read()，禁用math/rand（它不加密安全） - 盐值长度选 16 字节（128 bit）足够，过长（如 64 字节）不提升安全性，只增加存储和传输开销
- 存储格式推荐 Base64 编码后与密文拼接，如
<salt_b64>:<iter>:<key_b64></key_b64></iter></salt_b64>，解析时再解码；避免二进制裸存引发数据库字段截断
验证密码时要用 subtle.ConstantTimeCompare
直接用 == 比较两个密钥字节切片会触发时序攻击：攻击者通过响应时间差异能逐字节推断出正确密钥。
哪怕你用了 PBKDF2，若验证环节没做恒定时间比较，整套防护就前功尽弃。
- 必须用
crypto/subtle.ConstantTimeCompare()，且确保两个参数长度一致（否则直接返回 false） - 验证前先检查 salt+iter+hash 三元组是否完整，再解码 salt 和 hash，最后派生比对；不要在解析失败时提前 return，避免泄露字段结构
- 如果密钥长度固定（如始终 32 字节），可预先分配缓冲区并用
subtle.ConstantTimeCompare(got[:32], want[:32])，避免切片越界 panic
