Laravel 不内置访问量统计，手动用 DB::table() 记录并基于 session_id 或 IP+User-Agent+时间窗口去重，比盲目使用插件更可控、轻量、少坑。
直接说结论：Laravel 本身不内置访问量统计，但用 DB::table() 手动记录 + 合理去重（如基于 session_id 或 IP + User-Agent + 时间窗口），比盲目装插件更可控、更轻量、更少埋坑。
为什么别急着装「Laravel 访问统计插件」
市面上标榜「一键集成」的包（比如 laravel-visit-counter、statamic/visits 拿来硬套）常踩三个坑：
- 默认按
IP统计 → 公司/校园出口 IP 相同，多人算 1 次 - 写库不加索引 →
visits表几万条后，SELECT COUNT(*)直接变慢查询 - 混淆「PV」和「UV」：没区分页面级统计（某 URL 被刷 100 次）和站点级统计（独立访客数）
手动实现 UV 统计：用 session + 缓存兜底
要接近真实独立访客数，优先信任 session_id（已登录用户）或生成临时访客 ID（未登录用户），而非裸 IP。示例逻辑：
// 在 App\Http\Middleware\TrackVisitor.php 中
public function handle($request, Closure $next)
{
$sessionId = $request->session()->getId();
$visitorId = $sessionId ?: Str::uuid(); // 未登录时生成 UUID
// 写入缓存（避免高频写 DB），过期设为 24 小时
$key = 'uv:'.md5($visitorId);
if (!Cache::has($key)) {
Cache::put($key, true, 3600 * 24);
DB::table('page_visits')->insert(['type' => 'uv', 'created_at' => now()]);
}
return $next($request);}
注意：page_visits 表只需两个字段：type（可扩展为 home、product/123）、created_at；索引建在 type 和 created_at 上。
统计 PV：在控制器里显式调用，不自动触发
PV 是页面维度，应由业务代码决定何时计数 —— 比如只对公开文章页、商品详情页计，不对 API 接口、登录页、404 页计。不要全局中间件自动累加。
- 在
PostController@show里加一行：DB::table('page_visits')->insert(['type' => 'post:'.$post->id, 'created_at' => now()]); - 如果并发高，改用
Redis::incr("pv:post:{$post->id}")，再定时同步到 DB - 避免在 Blade 模板里用
{{ $post->increment('views') }}—— Eloquent save 会触发完整模型事件和日志，性能差
查数据别用 COUNT(*) 扫全表
线上跑一个月后，page_visits 表可能几十万行。直接 SELECT COUNT(*) FROM page_visits WHERE type = 'uv' 很慢。正确做法：
- 每天零点用 Artisan 命令聚合昨日 UV/PV 到汇总表（
daily_stats），查时只读这张小表 - 用
DB::select("SELECT DATE(created_at) d, COUNT(*) c FROM page_visits GROUP BY d ORDER BY d DESC LIMIT 7")替代多次单日查询 - 如果必须实时近似值，用 MySQL 的
SHOW TABLE STATUS LIKE 'page_visits'查Rows字段（误差约 10%，但快）
最易被忽略的一点：统计逻辑和业务逻辑混在同一数据库，一旦大促期间 page_visits 写入暴增，可能拖慢主业务事务。真要上量，UV/PV 表建议拆到单独数据库实例，或直接上 Redis + Logstash + Elasticsearch 链路。
