不能直接用 bcrypt.generatefrompassword 而不设成本因子，因其默认值10不适用所有场景：过低易被暴力破解，过高拖慢响应；需按cpu实测调整，新项目建议起始用12，并通过配置项动态管理。
为什么不能直接用 bcrypt.GenerateFromPassword 而不设成本因子
Go 的 bcrypt 包默认成本因子是 10，但这个值不是万能的。太低（比如 4）会让哈希在毫秒级就被暴力破解；太高（比如 20）可能让单次登录卡住几百毫秒，尤其在低配容器或高并发场景下拖垮响应。真实服务里，你得根据 CPU 能力实测调整。
实操建议：
- 新项目起步用
12，压测时观察bcrypt.Cost对http.HandlerP95 延迟的影响 - 已有系统升级成本因子时，必须兼容旧哈希：检查存储的哈希字符串是否以
$2a$、$2b$或$2y$开头，再决定是否重哈希 - 别硬编码数字——用配置项传入，例如
auth.bcrypt_cost=12，方便灰度切换
验证密码时 bcrypt.CompareHashAndPassword 返回 nil 但逻辑仍错？
这个函数只校验哈希是否匹配，**不校验输入密码长度、格式或是否为空**。常见错误是前端没做空值拦截，后端直接拿 "" 去比对，结果意外通过（某些旧版 bcrypt 实现对空密码处理不一致）。
实操建议：
- 在调用
bcrypt.CompareHashAndPassword前加显式判空：if len(password) == 0 { return errors.New("empty password") } - 数据库查用户时，确保查到的是有效记录——如果
user是 nil 或哈希字段为空，直接拒绝，别进比对流程 - 错误信息统一返回
"invalid credentials"，别暴露“用户不存在”或“密码错误”的细节，防枚举攻击
用 golang.org/x/crypto/bcrypt 还是第三方封装库？
官方维护的 golang.org/x/crypto/bcrypt 足够稳定，且无额外依赖。很多所谓“增强库”只是包了一层自动成本管理或上下文超时，反而增加调用链和出错路径。
实操建议：
- 坚持用官方包，导入路径必须是
golang.org/x/crypto/bcrypt（注意不是code.google.com/p/go.crypto/bcrypt，后者已废弃多年） - 避免使用带自动重哈希逻辑的 wrapper——它可能在你没意识到时触发写库操作，引发并发更新冲突
- 如果需要支持未来迁移算法（如 Argon2），抽象出
PasswordHasher接口，但实现层仍直调bcrypt，别过早抽象
测试里写死 bcrypt.GenerateFromPassword([]byte("test"), 4) 会出什么问题？
成本因子设为 4 会导致测试运行飞快，但掩盖了真实哈希耗时——你无法发现生产环境因成本因子升高导致的 timeout 或 goroutine 积压。更糟的是，某些 CI 环境 CPU 共享严重，低因子哈希可能快得反常，掩盖性能退化。
实操建议：
- 单元测试中固定用
bcrypt.MinCost（当前是4），但集成测试必须用实际部署值（如12），并监控执行时间 - 写 benchmark 时，明确标注成本因子：
func BenchmarkBCrypt12(b *testing.B)，别混用 - CI 流水线里加一道检查：扫描代码禁止出现
GenerateFromPassword.*10这类硬编码（用grep -r "GenerateFromPassword.*[0-9]" ./...）
bcrypt 不是设个函数就完事的黑盒——成本因子要测，空密码要拦，哈希字符串要解析，测试值要分层。最容易被忽略的，是升级成本因子时忘了旧数据怎么平滑过渡。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
