评估静态化改造成果核心是看静态请求占比提升、响应质量（200/304占比、缓存头、$request_time分布）、流量分布合理性（资源类型/referer/user-agent）及时间规律稳定性，需通过日志分离、打标、多维交叉验证。
评估静态化改造成果，核心是看“多少请求被 Nginx 直接响应”以及“这些请求是否符合预期分布”。不能只比总量，而要从日志中分离、打标、分层验证——重点看静态资源请求占比、命中质量、来源结构和时间规律。
分离静态请求并确认占比提升
静态化成功的第一信号，是静态资源请求在总流量中的占比显著上升。需先确保日志已按后缀或路径精准剥离：
- 检查是否已配置独立 location 捕获常见静态后缀（.js、.css、.png、woff2、svg等），且启用专用 access_log
- 用 awk 统计静态日志占总日志比例：
awk 'NR==FNR{t++} FNR==NR && /.(js|css|png|jpg|gif|woff2)/{s++} END{printf "静态请求占比: %.2f%%\n", s/t*100}' /var/log/nginx/access.log /var/log/nginx/static_access.log - 对比改造前后该比例变化：若从 40% 升至 75%+，说明动静分离基本落地；若无明显变化，需排查 location 规则是否被 proxy_pass 覆盖，或前端资源未走预期路径
验证静态响应质量与缓存效果
高占比不等于高质量。需结合状态码、响应头与耗时判断是否真由 Nginx 高效服务：
- 检查静态日志中 200 和 304 状态码占比：304 应明显上升（表示浏览器缓存生效）
awk '$4 ~ /^200|304$/ {c++} NR==FNR{t++} END{printf "有效响应率: %.2f%%\n", c/t*100}' /var/log/nginx/static_access.log - 确认 expires 或 Cache-Control 头是否生效：在日志中加 $sent_http_expires 或 $sent_http_cache_control 字段，筛选出未带缓存头的请求，定位漏配路径
- 观察 $request_time 分布：静态请求应集中在 0.001–0.02 秒区间；若大量 >0.1 秒，可能因磁盘 I/O、权限问题或误走代理逻辑
分析真实流量分布是否合理
静态化后流量不应均匀分散，而应呈现典型“长尾+头部集中”特征。需多维交叉验证：
- 按资源类型分布：JS/CSS 占比通常 25–40%，图片类（png/jpg/svg）占 45–60%，字体/图标等占剩余部分。若 JS 请求远超图片，可能打包策略异常或监控脚本污染
- 按 Referer 域名分布：主站域名应占绝对多数（>85%）；若大量来自未知第三方或爬虫域名，需检查资源是否被外链盗用
- 按 User-Agent 分布：主流浏览器（Chrome/Firefox/Safari）应覆盖 90%+；若出现大量“curl”“python-requests”，可能是监控探测或恶意扫描
观测时间维度上的稳定性与峰谷匹配
静态资源访问具备强时间规律性，可反推改造是否影响用户行为：
- 绘制每小时静态请求数曲线，应与业务高峰一致（如工作日上午 9–11 点、下午 2–4 点），且夜间低谷稳定（非断崖式归零）
- 对比改造前后同一时段的 PV/UV 比值：若静态 PV 上升但 UV 下降，可能因 CDN 缓存过强导致重复用户未触发新请求，需调低 cache key 粒度
- 检查凌晨 3–5 点是否存在异常 HTTP 请求突增（尤其非 HTTPS），这常暴露旧版 App 或自动化工具未升级，仍直连源站取资源
