Buffalo 框架不内置用户系统，推荐用 buffalo generate auth 生成完整认证流程，含 User 模型、路由、session 配置及中间件；需显式注册 auth.Required 中间件防 panic，扩展功能如密码重置和 session 活跃管理须手动闭环实现。
Buffalo 框架本身不提供开箱即用的用户系统，它把注册、登录、权限这些事交给你选：要么用 buffalo-auth 插件快速生成基础能力，要么从零手写——但手写容易漏 session 持久化、CSRF 防御或密码哈希校验，不推荐。
用 buffalo generate auth 生成基础用户流程
这是最省力也最不容易出错的方式。它不是“半成品”，而是直接产出可运行的 User 模型、表单路由、session 配置和中间件。
- 运行
buffalo generate auth后，models/user.go自动包含Email和PasswordHash字段，迁移文件也一并生成 -
actions/auth.go里已有Login、Register、Logout和CurrentUser四个 handler，不用再写绑定逻辑 - 表单字段名必须严格为
email和password（Register需两者，Login只需这两项） - 登录成功后，
current_user会自动注入模板上下文，模板中可直接写{{ current_user.Email }} - 注意：该命令默认不启用邮箱验证或失败锁定，需要就得自己改
Loginhandler
为什么 auth.CurrentUser(r) 会 panic？
常见报错 invalid memory address or nil pointer dereference，根本原因是没走认证中间件，导致 r.Session() 是 nil。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 必须在
app.go的路由注册处显式使用中间件，例如：app.Use(auth.Required) - 不要在未受保护的路由（如
/public或/health）里直接调auth.CurrentUser(r)；先判空：if u := auth.CurrentUser(r); u != nil { ... } - 若用了自定义 session 存储（如 Redis），要确保
session.Store已初始化，否则r.Session()返回nil，后续所有.Get()都崩 -
auth.Required只检查 session 是否存在，不校验用户是否被禁用或 token 是否过期——这些得你额外加逻辑
如何扩展密码重置功能
buffalo-auth 不生成重置流程，但留好了接口。关键不是多写几个 handler，而是保证 token 生成、存储和校验闭环。
- 在
User模型里加两个字段：ResetToken string和ResetSentAt time.Time，然后跑一次 migration - 新建
ResetPasswordaction：生成uuid.NewString()，存进ResetToken并更新ResetSentAt，再用gomail发送带/reset?token=xxx的邮件 -
Resetaction 要做三件事：查 token 是否存在且未超时（比如 1 小时）、清空旧 token、用新密码更新PasswordHash - 别忘了在重置成功后清除 session：
c.Session().Clear()+c.Session().Save()，否则用户可能还挂着旧登录态
Session 过期不能只靠 MaxAge
设置 session.MaxAge = 1800 只能实现“登录后 30 分钟无请求就失效”，但用户开着页面不动，session 实际不会刷新，也就无法响应“长时间未操作”场景。
- 每次请求都得手动更新活跃时间：
c.Session().Set("last_activity", time.Now().Unix())，并调c.Session().Save() - 写一个独立中间件（如
CheckSessionActivity），放在App.Use()链靠前位置，在每次请求读last_activity，超时就c.Session().Clear()并重定向到/login - 前端需配合心跳：在页面加载后启动
setInterval(() => fetch("/api/keepalive", { method: "POST" }), 60_000)，后端/api/keepalivehandler 只更新last_activity并返回204 - 如果用 Redis 存 session，务必让 Redis key 的 TTL 和应用层的
last_activity判断逻辑对齐，否则 Redis key 过期了但代码还去读，会 panic 或静默失败
真正难的不是写几个 handler，而是 session 生命周期、活跃判断、前后端保活、存储后端 TTL 这四者必须严丝合缝——漏掉任意一环，用户就会遇到“明明刚操作过却突然被登出”或者“登出后还能继续点按钮”的问题。
