不能直接用 bcrypt.generatefrompassword 而不设成本因子，因其默认值10在现代硬件上已不足——攻击者可毫秒级暴力尝试数万次；硬编码固定值会导致新老用户安全水位不统一，必须显式指定如 bcrypt.cost12 并实测调优。
为什么不能直接用 bcrypt.GenerateFromPassword 而不设成本因子？
默认成本因子（bcrypt.DefaultCost，当前为 10）在现代硬件上已显不足——攻击者可在毫秒级完成数万次暴力尝试。硬编码固定值更危险：新用户用高成本哈希，老用户仍卡在低安全水位，无法统一升级。
实操建议：
- 新项目一律显式指定
bcrypt.Cost12或bcrypt.Cost14（需权衡 CPU 峰值压力） - 线上服务首次部署前，用
go test -bench=.测量目标机器上bcrypt.GenerateFromPassword([]byte("test"), bcrypt.Cost12)的耗时，确保 P99 - 避免把成本值写死在配置文件里——它应随哈希逻辑一起编译进验证流程，否则后续迁移易遗漏
如何识别并触发密码哈希的渐进式升级？
核心思路是：在每次成功登录时检查当前哈希是否匹配预期成本。若不匹配，就用新参数重哈希并更新数据库。关键不是“检测旧格式”，而是“检测当前哈希强度是否达标”。
常见错误现象：bcrypt.CompareHashAndPassword 成功后直接放行，完全跳过升级逻辑；或误判哈希前缀（如只看 $2a$）而忽略实际 cost 字段。
实操建议：
- 解析哈希字符串第三段（
$2a$10$...中的10），用strconv.Atoi提取 cost 值，与目标值（如 12）比较 - 升级必须发生在验证成功后、用户 session 创建前，且需加数据库行锁（如
SELECT ... FOR UPDATE）防止并发覆盖 - 绝不允许降级：若用户哈希 cost 已高于目标值（比如意外用了 14），保持原样，不主动降为 12
bcrypt.CompareHashAndPassword 返回 bcrypt.ErrMismatch 但密码明明正确？
这几乎一定是输入源问题：原始密码被截断、含不可见 Unicode 字符（如零宽空格）、或前端 JS 多次 encodeURI 导致后端收到双重 URL 编码字符串。
使用场景：调试阶段常在日志中打印 len(password) 和 fmt.Sprintf("% x", password) 对比字节序列，而非依赖 fmt.Println(password)。
实操建议：
- 在调用
bcrypt.CompareHashAndPassword前，先做bytes.TrimSpace，再确认长度是否在合理范围（如 8–128 字节） - 若前端传参经 JSON，确保 Go 结构体字段用
json:",string"标签防数字转字符串导致的隐式类型转换 - 测试用例必须覆盖含空格、制表符、中文、emoji 的密码，例如
"pass word\t?"
数据库字段设计要预留多长才能兼容未来成本升级？
bcrypt 输出长度随 cost 线性增长：cost 10 → 60 字符，cost 14 → 64 字符。看似只差 4 字，但若某天切换到 argon2 或支持 salt 长度扩展，字段太短会直接报错截断。
性能影响：VARCHAR(255) 与 VARCHAR(72) 在 InnoDB 中存储开销一致（都用 1 字节长度头），但语义清晰更重要。
实操建议：
- 密码字段统一设为
VARCHAR(255)，这是行业事实标准（Django、Rails、Laravel 全部采用） - 不要用 TEXT 类型——它强制走溢出页，反而降低高频验证的缓存命中率
- 建表时加注释：// bcrypt hash, max 64 chars now, keep room for future algo migration
ErrPasswordNeedsUpgrade 给前端——这等于向攻击者泄露账户状态。升级动作本身应静默，仅当数据库写失败时才按通用 DB 错误处理。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
