buffalo 框架不内置密码哈希，需手动调用 golang.org/x/crypto/bcrypt：注册时校验明文长度（0＜len≤72）、显式指定 cost=12、转 string 存入 varchar(255)/text；登录时须 trim 空格、判空、验长度 60，并在验证成功后手动解析哈希 cost 实现渐进式升级。
Buffalo 框架本身不内置密码哈希逻辑，它依赖 Go 生态的标准 bcrypt 实现（golang.org/x/crypto/bcrypt）。你得自己调用 bcrypt.GenerateFromPassword 和 bcrypt.CompareHashAndPassword，不能指望 Buffalo 自动生成或封装这层逻辑。
注册时怎么生成 bcrypt 哈希并存入数据库
在 Buffalo 的 action（比如 Create）里手动哈希密码，不是靠 ORM 或中间件自动处理：
- 明文密码必须先校验长度：
if len(pwd) == 0 || len(pwd) > 72，超长会被静默截断，导致后续验证永远失败 - 显式指定
cost参数，别用bcrypt.DefaultCost（=10）——并发高时响应明显拖慢；生产推荐12 - 调用后必须转成
string：hashedStr := string(hashed)，否则存进数据库可能出乱码或截断 - 数据库字段至少设为
VARCHAR(255)（MySQL）或TEXT（PostgreSQL），VARCHAR(60)是理论最小值，但留余量防 future 算法变更
登录时为什么 CompareHashAndPassword 总报 “invalid hash”
这不是密码错，是传进去的第一个参数根本不是合法哈希字符串。常见源头：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 数据库读出来时被 ORM 自动 trim 了前后空格，或者 JSON 反序列化时去掉了尾部换行——加一句
strings.TrimSpace(user.Password)再传 - 字段实际长度不足：用
len(user.Password)打印一下，不是 60 就立刻查库表结构和 GORM tag（比如漏写了gorm:"size:255"） - 读库后没判空：
if len(user.Password) == 0就该直接返回错误，避免把空串喂给 bcrypt 导致 panic - 哈希字符串被前端或中间件误当普通文本处理过（比如 URL decode、base64 decode），原始
$2a$10$...结构被破坏
password_needs_rehash 在 Buffalo 里不存在，得自己模拟
PHP 有 password_needs_rehash()，Go 没等价函数。如果你以后想升级 cost 值（比如从 12 升到 14），得手动解析哈希前缀：
- 用正则匹配哈希开头：
^\$2[abxy]\$(\d{2})\$，提取出 cost 数字 - 对比当前目标 cost，若小于，则在登录成功后重新哈希并更新数据库
- 注意：这个判断必须放在
bcrypt.CompareHashAndPassword成功之后，不能提前做——否则等于拿无效哈希去解析 - 别在注册流程里也做这个检查，只在用户凭正确密码登录成功的那一刻才触发平滑升级
最易被忽略的一点：Buffalo 的 Pop ORM 默认不会对 password 字段做任何特殊处理，哪怕你模型里写 Password string `json:"password" db:"password"`，它也不会自动哈希或过滤。所有安全逻辑都得你亲手写在 action 层，漏一行就等于裸奔。
