Revel拦截器仅在BEFORE、AFTER、PANIC、FINALLY四个时机介入Controller Action，不参与路由匹配与静态资源处理；函数拦截器（InterceptFunc）需传控制器类型指针，方法拦截器（InterceptMethod）绑定单个controller且方法须公开；BEFORE返回Result会终止后续执行但Session/Flash修改仍生效；CSRF等关键安全校验须在Filter层实现，而非依赖拦截器。
Revel 的拦截器（Interceptor）不是中间件，也不是过滤器（Filter），它只在 Controller Action 执行的四个明确时机介入：BEFORE、AFTER、PANIC、FINALLY。想靠它做请求头校验、JWT 解析、CSRF 检查？可以，但必须清楚它的能力边界——它不参与路由匹配、不处理静态资源、不拦截 Filter 阶段的逻辑（比如 SessionFilter 或 ParamsFilter 已执行完毕才轮到它）。
函数拦截器 vs 方法拦截器：签名和作用域差异必须分清
两者返回值都是 revel.Result，但签名和绑定方式完全不同，混用会导致注册失败或静默忽略：
-
InterceptFunc接收*revel.Controller参数，适用于全局通用逻辑（如统一鉴权、日志打点），注册时需显式指定作用范围，例如：revel.InterceptFunc(checkAuth, revel.BEFORE, &AppController{})注意第三个参数是控制器类型指针，不是实例；传nil表示全局生效，但部分 Revel 版本（如 1.1.0）对此支持不稳定，建议显式传入具体 controller 类型。 -
InterceptMethod接收的是方法接收者，签名必须为func (c *MyController) AuthCheck() revel.Result或func (c MyController) AuthCheck() revel.Result。它只能绑定到某一个 controller 及其子类，不能跨 controller 复用，且方法名必须是公开的（首字母大写）。 - 常见错误：把
checkAuth(c *revel.Controller)误传给InterceptMethod，会编译报错或运行时报panic: method not found；反过来把MyController.AuthCheck传给InterceptFunc，则根本不会被调用。
BEFORE 拦截器中提前返回 Result 的副作用很直接
在 BEFORE 阶段返回非 nil 的 revel.Result（比如 c.Redirect 或 c.RenderError），会立即终止整个拦截链和后续 action 调用——这没错，但容易忽略两点：
- session 和 flash 数据已解码并可读写，但如果你在拦截器里修改了
c.Session或c.Flash，这些变更**仍会生效**，哪怕后续 action 没执行。所以不要假设“跳转 = 状态干净”，该清理的 session key 得手动删。 - 如果多个
BEFORE拦截器按序注册，前一个返回了Result，后一个根本不会执行。别指望靠“第二个拦截器兜底重定向”——顺序就是执行顺序，没有 fallback 机制。 - 典型陷阱：在 JWT 校验拦截器里解析 token 后把用户信息存进
c.Params，结果因权限不足提前跳转，下个拦截器（比如审计日志）试图读c.Params.Get("user_id")就 panic，因为c.Params是只读映射，且未初始化该 key。
企业级安全实践：别只靠拦截器做全部验证
拦截器适合做「业务层前置检查」，但 Web 安全的关键防线不该只放在这里：
- CSRF Token 验证必须在
ParamsFilter之后、BEFORE拦截器之前完成——Revel 原生不提供 CSRF Filter，得自己写一个Filter插入到ParamsFilter和InterceptorFilter之间，否则攻击者绕过拦截器直击 action 也能提交伪造表单。 - 敏感操作（如密码修改、资金转账）的二次确认（如短信验证码）不能只靠前端隐藏字段或 cookie 标记，必须在拦截器里重新校验时效性、唯一性和绑定关系，且校验失败时用
c.RenderError(400)而非c.Redirect，避免重定向泄露状态。 - 日志脱敏必须在
BEFORE和AFTER都做：前者记录原始请求（含 token、密码字段需打码），后者记录响应状态与耗时。别等FINALLY——它在 response 写出后才触发，若网络中断或客户端断连，日志可能丢失。
真正难处理的，是拦截器和 Filter 的协作边界：比如你想在拦截器里读取自定义请求头 X-Request-ID 并注入到日志上下文，但 ParamsFilter 并不解析 header，得自己写 Filter 提前提取并挂到 c.Request.Header 上——这时候拦截器才能安全使用。这个耦合点，文档从不提，但线上故障常源于此。
