用 preg_match 提取日志中 Referer 字段更可靠；需处理空值、中文域名、微信等特殊 referer；统一提取根域名后统计频次并过滤噪音；PHP 输出 JSON 数据，前端用 Chart.js 渲染饼图；referer 不可靠，须结合 utm 参数、JS 上报等补救。
用 PHP 解析 Apache/Nginx 日志提取 referer
直接读原始日志是第一步，但别硬写正则去拆整个日志行——preg_match 匹配 Referer: 字段更稳。Nginx 默认日志格式里 $http_referer 是独立字段，Apache 的 combined 格式也包含它，位置通常在倒数第二列（用空格或双引号分隔）。实际解析时建议先用 file() 读取小样本，用 var_dump() 看清结构再写匹配逻辑。
常见坑：
- 日志里大量 - 表示空 referer（直接输入 URL 或 HTTPS→HTTP 跳转丢失），得单独归为“直接访问”类
- 中文域名、特殊符号（如 %20）需用 urldecode() + mb_substr() 截取主域名，避免把 www.example.com/search?q=php%20log 当成不同来源
- 微信内置浏览器的 referer 是 https://mp.weixin.qq.com/，但实际应归为“微信”，需规则前置判断
用 array_count_values 统计域名频次并过滤噪音
拿到原始 referer 列表后，用 array_map 统一提取根域名（比如用 parse_url($r, PHP_URL_HOST) 再 ltrim 掉 www.），然后丢给 array_count_values。这步快，但必须过滤：
- 空值和
-（直接访问） - 本站域名（
$_SERVER['HTTP_HOST']）——防止内部跳转污染数据 - 搜索引擎子域泛滥（如
images.google.com、encrypted.google.com全部合并到google.com） - 短链服务（
t.co、bit.ly）按业务需求决定是否展开或丢弃
统计完建议用 arsort 倒序，再用 array_slice 取前 10 名——饼图塞不下 50 个 slice。
用 Chart.js 在前端渲染来源饼图（不装 PHP 图形扩展）
PHP 本身不擅长绘图，硬上 GD 或 Imagick 生成 PNG 饼图既慢又难调样式。更实用的做法：PHP 只输出 JSON 数据，前端用 Chart.js 渲染。关键点：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“PHP免费学习笔记（深入）”；
后端输出类似：
echo json_encode([
'labels' => ['google.com', 'baidu.com', 'direct', 'weixin.qq.com'],
'data' => [423, 187, 305, 92]
]);前端 JS 里用 fetch 拿到后，传给 new Chart(ctx, { type: 'pie', data: {...} })。注意：
- labels 中文要确保 PHP 文件是 UTF-8 编码，且 HTTP header 发送 Content-Type: application/json; charset=utf-8
- 如果日志量大（单日 > 10 万行），别在页面加载时实时解析，改用定时脚本（crontab）预处理成 JSON 文件，PHP 直接 file_get_contents 读取
referer 分析的天然缺陷与补救思路
单纯依赖 referer 极不可靠：
- 浏览器隐私设置（如 Firefox 的 referrerpolicy="no-referrer"）会清空字段
- HTTPS 页面跳转到 HTTP 页面时，浏览器强制清空 referer
- App 内嵌 WebView、小程序等场景根本无 referer
所以真实项目中，务必结合其他手段：
- 在落地页加 utm_source 参数（如广告链接带 ?utm_source=wechat）
- 用 JavaScript 检测 document.referrer 并上报到后端（比服务端日志更全）
- 对于登录用户，用数据库关联行为路径，反推来源
日志里的 referer 只是拼图的一角，别把它当唯一真相。
