拦截器(Interceptor)是一种在请求/响应或方法调用前后插入自定义逻辑的设计模式,广泛用于 Web 开发、RPC、消息处理等场景。下面按常见技术栈 + 典型使用场景来说明。
用途:判断用户是否登录、Token 是否有效
示例:
Token / Session✅ 统一处理,不用在每个接口里写鉴权逻辑
用途:判断用户是否有权限访问某个接口
示例:
用途:记录请求信息,用于监控或审计
示例:
用途:在业务执行前统一处理参数
示例:
用途:在拦截器中捕获异常并包装返回
示例:
用途:防止接口被恶意调用
示例:
用途:统一返回结构
示例:
{
"code": 200,
"msg": "success",
"data": ...
}
用途:在请求进入前统一设置跨域头
示例:
Access-Control-Allow-Origin✅ 服务调用链日志
✅ 分布式链路追踪(TraceId)
✅ 服务鉴权
✅ 超时控制
✅ 负载均衡扩展
✅ 灰度发布 / 标签路由
✅ 消息发送 / 消费前后埋点
✅ 消息内容校验
✅ 消息加密 / 解密
✅ 消息轨迹记录
✅ SQL 执行日志
✅ 分页插件
✅ 数据加解密
✅ 逻辑删除
✅ 自动填充字段(创建时间、更新时间)
✅ 自动携带 Token
✅ 请求参数加密
✅ 统一设置 Header
✅ 统一错误处理
✅ Token 过期自动刷新
✅ 数据格式转换
| 类型 | 作用范围 | 典型用途 |
|---|---|---|
| Filter | Servlet 层 | 编码、CORS、请求日志 |
| Interceptor | MVC 层 | 登录、权限、业务处理 |
| AOP | 方法级 | 事务、日志、缓存 |
拦截器适合做“横切关注点”的事情
凡是多个接口 / 方法都需要、但与具体业务无关的逻辑,都适合用拦截器。
如果你告诉我你用的是:
我可以给你针对该框架的拦截器示例和最佳实践。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。