iris mvc注册路由和控制器需显式调用app.handle或app.register绑定方法，否则404；控制器方法名须按http动词+大驼峰命名（如postregister），且结构体字段首字母大写以支持依赖注入。
注册路由和控制器怎么配才不报404
Iris的MVC默认不自动注册控制器方法，Register必须显式调用，否则POST /register会直接404。常见错误是只写了app.Handle("POST", "/register", ...)但没走MVC流程，导致无法注入依赖或校验器失效。
正确做法是用app.RegisterView配合app.Handle或更推荐的app.ConfigureContainer + app.Party分组注册：
- 在
main.go中创建Party并调用Register：auth := app.Party("/auth") auth.Register(new(AuthController)) -
AuthController里定义PostRegister方法（Iris按HTTP动词+大驼峰匹配） - 确保控制器结构体字段名首字母大写，否则依赖注入失败
用户数据怎么安全地从表单进数据库
Iris的Bind方法默认绑定JSON或表单，但容易忽略Content-Type校验和字段过滤。比如前端发application/x-www-form-urlencoded，后端没设iris.WithoutBodyDecoder可能解析失败；又或者用户提交is_admin=1字段，而结构体里漏了json:"-" form:"-"忽略，就会被意外写入。
实操建议：
- 定义注册结构体时，所有字段加
form标签，并用validate约束：type RegisterReq struct { Username string `form:"username" validate:"required,min=3,max=20"` Password string `form:"password" validate:"required,min=6"` Email string `form:"email" validate:"required,email"` } - 在控制器方法里先
c.ReadForm(&req)，再validator.New().Struct(req)手动校验（Iris内置校验器不支持form标签，得自己桥接） - 密码必须用
golang.org/x/crypto/bcrypt哈希，别直接存明文或用md5
为什么注册成功后跳转总丢失session或闪存消息
Iris的Flash依赖session中间件，但很多人只加了iris.Sessions却忘了配置Cookie选项，导致跨域或HTTPS下Set-Cookie被浏览器拒绝。典型现象是注册后c.Flash().Set("success", "ok")，重定向到登录页却读不到。
关键点：
- 初始化session时必须显式设置
Cookie.HttpOnly和Cookie.Secure（HTTPS环境）：sessions := sessions.New(sessions.Config{ Cookie: "my_session", CookieSecure: true, // HTTPS必须开 CookieHTTPOnly: true, }) - 重定向前调用
c.Redirect而不是c.JSON，且不能在PostRegister里提前return，否则Flash来不及写入 - 跳转目标页面（如
/login）的模板里要用{{.Flash.success}}取值，不是{{.Flash.Get}}
邮箱唯一性校验失败却没提示，问题出在哪
数据库层唯一约束（如MySQL的UNIQUE KEY email）触发时，GORM或SQLx返回的是底层驱动错误，比如Error 1062: Duplicate entry 'x@y.z' for key 'users.email'，但Iris不会自动转成用户友好的提示。直接if err != nil { c.JSON(400, iris.Map{"error": err.Error()}) }会暴露数据库细节，还可能被绕过校验逻辑。
应该：
- 在插入前主动查一次：
db.Where("email = ?", req.Email).First(&user).RowsAffected == 0 - 如果用GORM，捕获
gorm.ErrRecordNotFound以外的错误，再用errors.Is(err, gorm.ErrDuplicatedKey)（v1.25+）判断唯一冲突 - 避免用
defer db.Close()在控制器里关连接——Iris的DB实例应全局复用，关了会导致后续请求panic
真正麻烦的是并发注册：两个请求几乎同时通过“查无此人”校验，然后都插入成功。这时候只能靠数据库唯一索引兜底，再捕获错误重试或返回通用提示，别指望应用层完全锁住。
