Revel框架默认不拦截User-Agent，需手动在app/init.go中注册CheckUA等拦截器，通过正则匹配真实浏览器特征，并配合Sec-Fetch-*、Referer、IP-UA频率等多维度校验，且须避开静态资源与健康检查路径。
Revel框架默认不拦截User-Agent，必须手动配置
Revel本身是Go语言的MVC框架，它不像Django或Spring Security那样内置反爬中间件。所有UA识别、IP限流、请求头校验都得自己写Interceptor或在App.Init阶段注册过滤逻辑。如果你没显式检查User-Agent，那任何UA——包括python-requests/2.28.1或空UA——都能直通后端。
常见错误是以为加了revel.Intercept就自动防爬，其实它只是钩子容器，不写判断逻辑等于没设防。
- 必须在
app/init.go里注册一个拦截器，比如CheckUA - 拦截器要读取
c.Request.Header.Get("User-Agent")，再做白名单或黑名单匹配 - 建议用正则而非
strings.Contains，避免被curl/7.68.0 (fake-user-agent)这类绕过 - 别只拦
python-前缀，很多爬虫会伪造成Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36但实际是headless模式
用正则白名单比黑名单更可靠，但要注意内核版本漂移
直接写死Chrome 120的UA字符串会很快失效——用户浏览器升级、爬虫工具同步更新UA库，你的正则一松动就放行。更稳的做法是提取关键特征：操作系统标识 + 渲染引擎 + 主流浏览器名。
例如这个正则能覆盖95%真实浏览器，同时排除大部分静态爬虫：
^(Mozilla\/5\.0 \(.*?(Windows|Macintosh|iPhone|iPad|Android).*?\) AppleWebKit\/\d+\.\d+ \(KHTML, like Gecko\) (Chrome\/\d+|Firefox\/\d+|Safari\/\d+|Edg\/\d+)).*$
注意点：
- 不要忽略
Edg（Edge）和Safari的移动版UA，它们结构差异大 - 移动端UA常含
Mobile关键词，但不是所有都带，iOS Safari 17+已省略 - 如果业务允许微信内置浏览器，得额外加
MicroMessenger分支，否则大量国内流量被误杀 - 匹配失败时返回
403比404更合理——暴露接口存在但拒绝访问，降低爬虫试探成本
单靠User-Agent识别容易被绕过，必须配合其他信号
纯UA检测在2026年已基本失效。真实爬虫工具（如Playwright、Colly）能完美复现任意UA+Accept头+语言偏好，甚至模拟Sec-Ch-Ua等Chromium新标头。只查UA等于开门揖盗。
必须叠加至少一项辅助判断：
- 检查
Sec-Fetch-*系列头（如Sec-Fetch-Mode: navigate），真实浏览器才有，requests/curl默认不发 - 验证
Referer是否为空或来自非预期域名（比如你首页是https://example.com，但请求却带Referer: https://evil.com） - 记录同一IP的
User-Agent切换频率，1分钟内换5个不同UA基本可判为爬虫（人类不会这么干） - 对高风险路径（如
/api/v1/items）要求携带X-Requested-With: XMLHttpRequest，并校验是否与UA行为一致
Revel里UA拦截要避开静态资源和健康检查端点
如果把UA校验放在全局Intercept里，连/public/js/app.js或/healthz都会被拦，导致前端加载失败或K8s探针报错。
正确做法是按路径分层控制：
- 在
routes.conf中给敏感API路由打标签，比如GET /api/* Controller.Method [auth] - 拦截器里用
c.Request.URL.Path做前缀匹配，只对/api/和/admin/生效 - 明确放行
/robots.txt、/favicon.ico、/healthz等路径，避免监控告警误触发 - 若用了CDN或WAF（如Cloudflare），优先在边缘层做UA过滤，减轻Revel实例压力
最易被忽略的是调试阶段——本地用curl -H "User-Agent: xxx"测试时，可能忘了清除缓存或绕过CDN，结果测出来正常，上线后却被WAF先拦了。务必在生产环境链路末端验证拦截效果。
