Revel拦截器是Controller层请求生命周期钩子，非中间件；它在Action执行前后触发，不操作原始HTTP对象，依赖Filter链（如SessionFilter）预加载数据，函数拦截器全局生效，方法拦截器绑定特定Controller，BEFORE/AFTER返回revel.Result可中断或替换响应，PANIC拦截器捕获panic，FINALLY用于资源清理。
Revel 拦截器不是中间件，是请求生命周期钩子
Revel 没有传统意义上的“中间件”概念，所谓拦截器（Interceptor）本质是嵌入在 ActionInvoker 前后、受控于 revel.Filters 链的函数或方法，它不接管 HTTP 流程，也不操作 http.ResponseWriter 或 http.Request 原始对象。真正处理网络层的是 Filter 链（如 RouterFilter、SessionFilter），而拦截器只作用于 Controller 层——也就是路由匹配成功、参数/Session 已就绪、但 Controller.Action() 尚未执行（BEFORE）或刚执行完（AFTER）的瞬间。
常见误解是把拦截器当过滤器用，比如试图在 BEFORE 拦截器里调用 c.Response.Out.WriteHeader() 或提前写响应体，这会和后续 ActionInvoker 冲突，触发 http: multiple response.WriteHeader calls 错误。
函数拦截器 vs 方法拦截器：绑定粒度与上下文访问差异
函数拦截器签名固定为 func(*revel.Controller) revel.Result，它不依赖具体 Controller 类型，可全局注册；方法拦截器必须定义在某个 Controller 结构体上，签名是 func(c YourController) revel.Result 或 func(c *YourController) revel.Result，只能对该 Controller 或其子类生效。
- 函数拦截器无法直接访问
YourController特有字段，只能通过c.Params、c.Session等通用接口取值 - 方法拦截器可自由读写
c的成员变量，适合做状态预置（如初始化 DB 查询器）、权限校验（如检查c.User.Role） - 若注册了
revel.InterceptMethod((*AppController).AuthCheck, revel.BEFORE)，但某个 Action 是在AdminController里定义的且未继承AppController，该拦截器不会触发
拦截时机决定能否捕获 panic 和是否影响响应流程
BEFORE 和 AFTER 拦截器对 panic 不敏感——一旦 Controller Action panic，它们就跳过了；只有 PANIC 类型拦截器能兜住，且必须在 revel.Filters 中排在 revel.PanicFilter 之后才能生效（否则 panic 已被框架默认 recover 并转为 500 页面）。
FINALLY 拦截器总能执行，但此时响应已写出、连接可能已关闭，不适合做日志记录（因 c.Response.Out 可能不可写），更适合清理 goroutine、关闭临时文件句柄等收尾动作。
-
BEFORE返回非nilrevel.Result→ 立即终止后续所有拦截器 + Action，返回该结果 -
AFTER返回非nilrevel.Result→ 替换当前 Action 返回的结果，但其他AFTER拦截器仍会继续运行 - 多个
AFTER拦截器都返回revel.Result，最终生效的是最后一个
拦截器不能替代 Filter，尤其涉及 Session 或 CSRF 时
比如你想做登录态校验，用拦截器读 c.Session.Get("user_id") 是可行的，但若 Session 还没加载（即 SessionFilter 没执行），这个值就是空——因为拦截器执行顺序由 revel.InterceptFunc() 调用时机决定，而 SessionFilter 是在 ParamsFilter 之后、InterceptorFilter 之前运行的。所以，任何依赖 Session、Flash、CSRF Token 的逻辑，必须确保对应 Filter 已完成，否则 c.Session 或 c.RenderArgs["csrf_token"] 都是未初始化状态。
典型错误配置是把 csrf.CSRFFilter 放在 SessionFilter 之前，导致 token 校验失败返回 403；同理，若你在 BEFORE 拦截器里手动修改 c.Session，但没调用 c.Session.Save()，变更也不会持久化——因为 SessionFilter 的 FINALLY 阶段才负责写 cookie。
真正容易被忽略的是：拦截器本身不参与请求流控制，它只是 Controller 层的“钩子”，别指望它能像 net/http.Handler 那样短路整个 HTTP 请求。要改响应头、重定向、拒绝访问，得靠 Filter 或直接返回 revel.Result —— 但后者只对当前 Action 生效。
