首选 bcrypt 是因其内置唯一随机盐值和可调成本因子，天然抗彩虹表攻击；md5/sha256 即使加盐也易受针对性彩虹表攻击，且 diy 拼接易出错；推荐 cost factor 为 10–12，需压测确保单请求 ≤100ms；校验必须用恒定时间的 comparehashandpassword 防时序攻击；盐值绝不复用，数据库只需存完整哈希字符串；旧系统迁移须强制重置密码；bcrypt 仅防暴力破解，需配合频次限制、mfa 等措施。
直接用 bcrypt + 独立盐值 + 合理 cost factor，别自己拼接哈希，也别复用 salt。
为什么 bcrypt 是首选而非 md5/sha256
彩虹表攻击依赖预计算的哈希-明文映射表，而 bcrypt 在设计上就内置抗此攻击的能力：每次调用自动产生唯一 salt，且 salt 与哈希结果一起序列化存储（如 $2a$10$... 格式），无需额外字段。md5/sha256 即使加盐，若 salt 固定或可预测，仍可能被针对性构造彩虹表。
-
bcrypt的 salt 是加密安全随机生成的，长度足够（默认 128 位），且绑定到单次哈希过程 - 标准库
golang.org/x/crypto/bcrypt的GenerateFromPassword已封装全部逻辑，无需手动管理 salt 存储 - 避免用
sha256.Sum256([]byte(salt + password))这类 DIY 方案——salt 长度、生成方式、拼接顺序都易出错
cost factor 设多少才既安全又不拖垮服务
cost factor 控制 bcrypt 内部 Blowfish 加密轮数，每 +1，耗时约翻倍。设太高会阻塞登录接口；太低则给暴力破解留出空间。当前生产环境推荐值是 10 到 12，取决于你的 CPU 能力和并发量。
- 用
bcrypt.DefaultCost（目前为 10）作为起点，压测登录路径：单请求平均耗时应 ≤ 100ms - 若 API QPS > 500 且 CPU 常驻 70%+，谨慎升到 12；低于 100 QPS 可直接用 12
- 绝对不要用
4或6—— 现代 GPU 一秒能试几万次，形同裸奔
校验密码时必须用 bcrypt.CompareHashAndPassword
直接比对哈希字符串（如 ==）会引入时序攻击风险：CompareHashAndPassword 内部使用恒定时间比较，避免攻击者通过响应延迟推断 hash 前缀。
- 错误写法：
if storedHash == bcrypt.GenerateFromPassword(...)—— 完全没意义，且暴露时序侧信道 - 正确写法：
err := bcrypt.CompareHashAndPassword(storedHash, inputPassword)，只关心err == nil - 即使用户不存在，也要走完整校验流程（即查库+比对），防止用户名枚举
盐值不能“共享”或“复用”
每个用户密码必须独立哈希，salt 绝对不可跨用户、跨系统、跨时间复用。常见误操作包括：用固定字符串当 salt、从配置读 salt、用用户 ID 当 salt。
- bcrypt 的 salt 已内嵌在哈希字符串里（
$2a$10$...中$分隔的第二段），解码后自动提取，无需你存单独字段 - 数据库字段只需存完整哈希字符串（通常 60 字符），别拆开存 salt 和 hash
- 迁移旧系统时，若原密码是 md5+固定 salt，必须强制用户重置密码，不能“升级哈希”——旧 salt 已失效
真正容易被忽略的是：bcrypt 只防暴力破解，不防撞库或钓鱼。它必须配合其他措施——比如登录频次限制（用 ulule/limiter + Redis）、多因素认证、以及前端密码强度提示。哈希再强，用户输 123456 也没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
