Iris 框架无内置 MVC，爬虫拦截需通过中间件实现；应组合 User-Agent 特征、关键请求头缺失及 IP 频率限流（推荐 Redis）进行识别；动态防护可采用 HTML class 混淆、X-Device-ID 校验等轻量手段。
Iris 框架本身不内置“MVC 分层”概念，它是一个轻量、高性能的 Go Web 框架，强调路由和中间件驱动；所谓“MVC 模式下拦截爬虫”，实际是指在 Iris 应用中，把控制器（handler）、模型（业务逻辑）、视图（模板渲染）组织起来的同时，在请求进入 controller 之前，用中间件做爬虫识别与拦截。
为什么不能直接复用 Spring MVC 那套拦截器思路
Go 没有统一的“拦截器接口”抽象，Iris 的 Handler 就是 func(ctx iris.Context)，所有前置逻辑都靠中间件链（Use / UseGlobal）完成。你写一个 CheckBotMiddleware，它就跑在所有路由 handler 之前——这比 Spring 的 preHandle 更直接，但也更“裸”，没自动注入、没上下文生命周期管理。
常见错误是：把 Spring 的 Interceptor 概念硬搬进 Iris，试图注册“全局拦截器 bean”，结果发现框架根本不认这个类型。
-
Iris中间件必须是iris.Handler类型函数，不能是结构体方法或带依赖注入的类实例 - 想共享状态（比如 IP 计数），得自己传参或用闭包捕获，不能依赖框架容器
- 没有
postHandle或afterCompletion这种钩子，要记录日志或清理资源，得在中间件里手动defer或用ctx.OnResponse
怎么用中间件识别并拦截高频/异常 User-Agent
恶意爬虫常暴露在 User-Agent 头里（如 python-requests、curl/7.68.0、空 UA、明显伪造的浏览器字符串）。但仅靠 UA 黑名单容易误杀（比如某些企业内网客户端也用定制 UA），所以建议组合判断：
- 先检查
ctx.GetHeader("User-Agent")是否为空或匹配已知爬虫特征（正则：.*(?:bot|crawl|spider|slurp|archive|wget|curl|httpie).*） - 再查是否缺少关键人类行为头，比如
Accept、Accept-Language、Sec-Fetch-*等（真实浏览器几乎必带） - 对命中 UA 规则的请求，额外加一道 IP 频率校验（见下一条），避免单次误判就封禁
示例中间件片段：
func BotUAFilter() iris.Handler {
return func(ctx iris.Context) {
ua := ctx.GetHeader("User-Agent")
if ua == "" || regexp.MustCompile(`(?i)bot|crawl|spider`).MatchString(ua) {
// 不立即拒绝，先记日志 + 触发频率检查
ip := ctx.RemoteAddr()
if isFrequentIP(ip) {
ctx.StatusCode(429)
ctx.WriteString("Too many requests")
return
}
}
ctx.Next()
}
}
如何安全统计 IP 请求频率（避免 OOM 和多实例不一致）
直接用 map[string]int 存 IP 计数在单机开发时可行，但上线后会出问题：服务重启丢数据、多实例无法共享、无过期机制导致内存无限增长——尤其当爬虫用代理池打你时，map 很快爆掉。
正确做法是用带 TTL 的外部存储，Redis 是首选：
- 用
INCR+EXPIRE原子操作：每次请求执行INCR ip:192.168.1.100，若返回值为 1，则立刻EXPIRE ip:192.168.1.100 60 - 阈值设为 30 次/分钟，超过就返回
429并可选写入黑名单表 - 不要用
GET+INCR两步，避免竞态；Redis的EVAL脚本或 pipeline 更稳妥
如果暂时没 Redis，可用 github.com/go-redis/redis/v8 客户端封装一个简易限流器，别自己手写淘汰逻辑。
动态防护：让爬虫解析失败的最小成本方案
高级 WAF（如雷池）能动态混淆 HTML/JS，但 Iris 作为后端框架，不处理前端渲染细节。你能做的，是在返回 HTML 前插入轻量级干扰：
- 对非 API 路由（如
/posts/*），在ctx.View()前，用正则替换固定 class 名为随机字符串（btn-primary → x9f2j_btn），并把映射存 session 或 Redis，供 JS 运行时还原 - 关键数据接口（如
/api/items）强制要求携带X-Device-ID头，该 ID 由前端 JS 用navigator.hardwareConcurrency + screen.width拼接加密生成，服务端验证一致性 - 禁止
Referer为空且请求路径含.json或Accept: application/json的组合——这大概率是脚本直调，不是浏览器 AJAX
这些改动不依赖前端大改，但足以让大部分无头浏览器爬虫解析失败或漏数据。
真正难防的是用真实浏览器+分布式代理池的对手，这时候中间件能做的只是增加其成本；最终防线还是业务层的风控规则（比如单用户 1 小时只能导出 3 次数据）和日志联动 SIEM 做行为聚类分析。
