Revel框架需用Filter拦截请求并异步落库实现PV/UV统计；Controller内直接IO会阻塞goroutine、漏计静态资源与重定向请求，且多实例下无法去重；UV应基于user_id或IP+UA指纹，由存储层（如Redis SETNX）去重。
Revel 框架本身不提供内置访问量（PV/UV）统计模块，必须自行实现；直接在控制器里写 file_put_contents 或裸连数据库会破坏无状态设计、引发并发写冲突，且无法跨实例汇总——正确做法是用 Filter 拦截请求 + 异步落库/队列缓冲。
为什么不能在 Controller 里直接统计
Revel 的 Controller 是每次请求新建的实例，频繁 IO（如写文件、直连 DB）会阻塞 goroutine，降低吞吐。更关键的是：SessionFilter 和 FlashFilter 在 Filter 链中靠前执行，而统计逻辑若放在 Action 里，可能错过未登录用户、重定向请求或静态资源请求（如 /assets/js/app.js），导致 PV 漏计。
- 静态资源默认不走 Controller，
public/下文件由 Revel 内置 HTTP 处理器直接返回，不会触发任何 Filter 或 Action - Flash 消息依赖
FlashFilter，若统计逻辑放在After()方法中，而请求中途 panic 或被拦截，统计就丢失了 - 多个 Revel 实例部署时，各自写本地文件或独立 DB 表，UV 无法去重
用 Filter 实现全路径请求捕获
在 app/init.go 的 init() 函数中注册一个前置 Filter，确保它在 RouterFilter 之后、ActionInvoker 之前执行，这样既能拿到原始 URL，又不会遗漏任何合法路由请求：
revel.InterceptFunc(logVisit, revel.BEFORE, &Application{})
logVisit 函数内应避开耗时操作，只做轻量记录：
- 提取
c.Request.URL.Path和c.Request.Header.Get("User-Agent") - 用
c.Request.RemoteAddr做简易 IP 归一化（如 IPv6 转压缩格式，IPv4 截取前两段） - 将结构化数据发往内存队列（如
chan VisitRecord）或 Redis Stream，交由后台 goroutine 异步批量写入 - 切勿在此处调用
database.Exec或os.WriteFile
静态资源访问也要计入 PV？那得改 Revel 默认行为
Revel 默认把 public/ 映射到 /assets/ 并绕过所有 Filter —— 这意味着 /assets/css/admin.css 请求根本不会进你的统计 Filter。要统计这类请求，有两个选择：
- 放弃
public/目录，把所有前端资源挪到app/controllers下，用一个AssetsController统一返回，并在其中手动调用统计逻辑（适合小项目，但失去静态文件零拷贝优势） - 保持
public/不变，在 Nginx 层加日志：配置log_format stats "$time_iso8601|$remote_addr|$request_uri|$http_user_agent";，再用 Logstash 或自研脚本解析，和 Revel 应用日志合并分析（推荐，符合生产环境职责分离）
注意：若选后者，Nginx 的 access_log 必须开启，且不能用 buffer 或 flush 参数延迟写入，否则实时性差。
UV 去重的关键不是 Cookie，而是存储层设计
很多人以为读 c.Session.Get("uid") 就能算 UV，这是错的。Session 默认加密存 Cookie，用户清 Cookie 或换设备就重复计数；且未登录用户完全没 Session。真正可行的 UV 标识应满足：
- 对已登录用户，用后端生成的稳定
user_id（非 Session ID） - 对未登录用户，用
sha256(IP + UserAgent + Referer)生成指纹（注意不要含动态字段如时间戳） - 去重必须在存储层完成：Redis 的
SETNX或 PostgreSQL 的INSERT ... ON CONFLICT DO NOTHING，不能靠应用层 if-else 判断
尤其要注意：Revel 的 Session 在生产模式下默认禁用，session.cookie.secure = true 要求 HTTPS，否则 c.Session.Set 无效——这会让依赖 Session 的 UV 统计彻底失效。
