注册用 bcrypt 安全哈希密码并统一邮箱提示；登录用 CompareHashAndPassword 恒定时间比对且不区分错误类型；会话优先 gorilla/sessions+redis；sql 防注入用参数化查询，xss 防护需 html 清洗。
Go语言实现注册接口：别直接存明文密码
注册功能的核心不是“把数据写进数据库”，而是“安全地处理用户凭证”。bcrypt 是 Go 生态最稳妥的选择，它自动加盐、可调强度，且 bcrypt.GenerateFromPassword 返回的哈希值自带盐和参数，后续验证无需单独存盐。
常见错误是用 md5 或 sha256 自行拼接 salt——既容易写错逻辑，又无法抵抗彩虹表和 GPU 暴力破解。
实操建议：
- 用
golang.org/x/crypto/bcrypt，别自己造轮子 - 哈希强度设为
bcrypt.DefaultCost（目前是 10），不建议低于 8 - 注册时检查邮箱是否已存在，但返回提示统一为“该邮箱已被注册”，避免用户名探测
- 数据库字段类型选
VARCHAR(60)足够存 bcrypt 哈希（最长约 60 字符）
Go语言实现登录验证：用 bcrypt.CompareHashAndPassword 别手写比对
登录不是“查出密码哈希再自己比对字符串”，而是调用 bcrypt.CompareHashAndPassword。这个函数内部做了恒定时间比较（constant-time comparison），能防止计时攻击——如果用 == 直接比对，攻击者可通过响应时间差异推断哈希前缀。
立即学习“go语言免费学习笔记（深入）”；
典型错误是先查库拿到哈希，再用 strings.EqualFold 或 == 判断，这等于主动放弃安全防护。
实操建议：
- 查询用户时只依赖邮箱或用户名，不要在 WHERE 条件里带密码字段
- 查到用户后立即调用
bcrypt.CompareHashAndPassword，传入原始密码和数据库存的哈希值 - 无论比对成功与否，都走相同响应路径（比如统一延时 100ms），避免侧信道泄露
- 失败时返回泛化提示：“邮箱或密码错误”，不区分是用户不存在还是密码错
Session 管理用 gorilla/sessions 还是 JWT？看场景
短生命周期、服务端可控的会话（如后台管理系统）推荐 gorilla/sessions + Redis 后端；长时效、分布式或需跨域共享（如 app + Web）才考虑 JWT。
JWT 容易被滥用：很多人直接把用户 ID 和角色塞进 payload 并用 HS256 签名，却忽略密钥轮换、Token 撤回（黑名单）、过期刷新等现实问题。而 session ID 只是一个随机字符串，权限校验始终查服务端状态，更可控。
实操建议：
- 用
gorilla/sessions时，设置Options.httpOnly = true、Options.Secure = true（https 环境）、Options.SameSite = http.SameSiteStrictMode - session 存储别用内存（
cookiestore），生产环境必须用redisstore或数据库 - JWT 若必须用，签名密钥别硬编码，从环境变量读；且 payload 中只放不可变标识（如
user_id），权限信息每次请求查 DB
SQL 注入和 XSS 不是“加个库就完事”，得在关键位置做显式过滤
Go 的 database/sql 默认支持参数化查询，只要不用 fmt.Sprintf 拼 SQL 字符串，就能防注入——但很多人在动态构建 WHERE 条件（如搜索字段可选）时，又回到字符串拼接老路。
XSS 更隐蔽：模板渲染用户输入内容时，html/template 会自动转义，但一旦用了 {{.Content | safeHTML}} 或 template.HTML 类型，就等于放弃防护，而前端富文本编辑器返回的 HTML 往往未经清洗。
实操建议：
- 所有用户输入进 SQL 查询的地方，强制用
db.QueryRow("select ... WHERE name = ?", name)形式 - 需要动态列名或表名？白名单校验：
if !validcolumn(name) { return errors.New("invalid column") } - 渲染用户提交的 HTML 前，用
microcosm-cc/html-sanitize清洗，而不是信任safeHTML - API 返回 jsON 时，敏感字段（如密码哈希、手机号中间段）在 Struct tag 里加
json:"-"或手动 omit
登录注册看着简单，但密码存储、会话生命周期、错误提示粒度、输入边界控制，每一处松动都可能被放大成线上漏洞。真正难的不是写出能跑的代码，而是让每个分支都经得起“如果恶意用户这么操作，会发生什么”的推演。