应直接使用 bcrypt.GenerateFromPassword 一次生成带盐哈希，因其已封装 salt 生成、哈希计算与编码；迁移时避免硬编码格式，校验必须用 CompareHashAndPassword，切勿手动拼接或重哈希。
为什么不能直接用 bcrypt.GenerateFromPassword 存密码
直接调用 bcrypt.GenerateFromPassword 看似省事，但实际会隐式生成随机 salt 并和 hash 一起编码进返回的字符串（如 $2a$10$...）。这本身没问题，但容易让人误以为“加盐是框架自动兜底的，不用管”，从而忽略两个关键事实：
一是 salt 必须唯一且不可预测，bcrypt 库确实做到了；二是如果后续想迁移到其他哈希方案（比如 scrypt 或 argon2），硬编码依赖 bcrypt 的格式会让迁移变困难。更现实的问题是：有人会手写拼接 salt + password 再哈希，这完全绕过了 bcrypt 的 salt 管理逻辑，导致安全降级。
正确做法：用 bcrypt.GenerateFromPassword 一次到位
Go 的 golang.org/x/crypto/bcrypt 已经把 salt 生成、哈希计算、结果编码全封装好了。Echo 框架本身不参与密码哈希，你只需要在用户注册/修改密码的 handler 里调用它即可。重点不是“怎么加盐”，而是“别自己造轮子”。
实操建议：
-
cost参数建议设为12（即bcrypt.DefaultCost是 10，但硬件变快了，12 更稳妥） - 输入密码前先用
strings.TrimSpace去首尾空格，避免用户无意中输错空格却无法登录 - 哈希结果是字符串，直接存进数据库的
password_hash字段（长度至少 60 字符） - 不要拆解哈希字符串去单独存 salt ——
bcrypt的验证函数bcrypt.CompareHashAndPassword需要完整字符串
hash, err := bcrypt.GenerateFromPassword([]byte(user.Password), 12)
if err != nil {
return echo.NewHTTPError(http.StatusInternalServerError, "密码加密失败")
}
user.PasswordHash = string(hash) // 存这个
登录时必须用 bcrypt.CompareHashAndPassword 校验
常见错误是拿明文密码重新哈希后跟数据库值比对（==），这不仅慢，还可能因参数不一致导致误判。更危险的是：有人试图先从哈希串里解析出 salt 再手动哈希，这既没必要又易出错。
立即学习“go语言免费学习笔记（深入）”；
正确流程就一条：把数据库查出的完整哈希字符串和当前输入的明文密码交给 bcrypt.CompareHashAndPassword。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
注意点：
- 该函数内部会自动提取 salt、重算 hash、比较结果，全程不暴露中间值
- 即使密码错误，耗时也基本恒定（防计时攻击），无需额外处理
- 如果数据库字段为空或格式异常（比如不是
$2a$开头），CompareHashAndPassword会直接返回bcrypt.ErrMismatchedHashAndPassword，可据此区分“用户不存在”和“密码错误”
err := bcrypt.CompareHashAndPassword([]byte(user.PasswordHash), []byte(inputPassword))
if err != nil {
if errors.Is(err, bcrypt.ErrMismatchedHashAndPassword) {
return echo.NewHTTPError(http.StatusUnauthorized, "密码错误")
}
return echo.NewHTTPError(http.StatusInternalServerError, "校验失败")
}
别在 Echo middleware 或 validator 里做密码哈希
有人想把哈希逻辑塞进自定义 validator 或 middleware，比如用 echo.Context.Set 预处理密码字段。这会导致三个问题：一是职责混乱，密码哈希属于业务逻辑，不该混在请求生命周期控制里；二是难以测试，mock 不好 context；三是容易漏掉非 HTTP 路径的入口（比如 CLI 批量导入用户）。
真正该约束的是数据层：确保所有写入 PasswordHash 字段的地方都经过同一套哈希逻辑。可以封装成一个函数：
func HashPassword(pwd string) (string, error) {
pwd = strings.TrimSpace(pwd)
if pwd == "" {
return "", errors.New("密码不能为空")
}
hash, err := bcrypt.GenerateFromPassword([]byte(pwd), 12)
return string(hash), err
}
然后在 handler 里明确调用它。这样逻辑集中、边界清晰，后续加监控或替换算法也只改这一处。
最后提醒一句：别为了“兼容旧系统”而保留 MD5 或 SHA-1 的密码字段。真要迁移，就用“下次登录时升级哈希”的懒加载策略，而不是在代码里维护多套哈希路径。
