本文介绍在 laravel 8 中为约会类 web 应用设计高效、去重、可扩展的“每次获取一位未展示过的新用户”方案，重点解决基于地理位置优先级与活跃状态筛选后的顺序/随机去重分发问题。
本文介绍在 laravel 8 中为约会类 web 应用设计高效、去重、可扩展的“每次获取一位未展示过的新用户”方案，重点解决基于地理位置优先级与活跃状态筛选后的顺序/随机去重分发问题。
在构建类似 Tinder 的现代约会平台时，核心交互逻辑往往不依赖滑动（swipe），而是通过点击按钮触发不同操作（如“喜欢”“忽略”“稍后查看”）。此时，前端每次请求需返回一个从未向当前用户展示过的、符合业务规则（如地理位置近、在线、兴趣匹配）的目标用户——这要求后端具备“状态感知+去重分发+可中断恢复”的能力。
直接使用传统分页（如 paginate(1)）存在明显缺陷：页码固定导致用户刷新或跳转后重复返回同一记录；且无法天然排除已被展示过的用户 ID。更关键的是，真实场景中“最近”不等于“随机”，而应是以距离为主排序 + 活跃度为过滤条件 + 去重保障为前提的组合策略。
✅ 推荐方案：地理距离排序 + 状态过滤 + 已展示 ID 排除
Laravel 提供了灵活的查询构建能力，结合数据库地理函数（如 MySQL 的 ST_Distance_Sphere 或 Haversine 公式），可精准计算两点间球面距离。以下是一个生产就绪的实现示例：
use Illuminate\Support\Facades\DB;
// 假设已获取当前登录用户的经纬度
$currentUserLat = auth()->user()->latitude;
$currentUserLng = auth()->user()->longitude;
// 已展示过的用户 ID 数组（建议从 Redis 缓存读取，避免频繁查 DB）
$shownUserIds = Cache::get("user_".auth()->id()."_shown_ids", []);
// 构建带地理距离排序的查询（MySQL 5.7+）
$nextUser = DB::table('users')
->select('users.*', DB::raw('ST_Distance_Sphere(
POINT(?, ?),
POINT(users.longitude, users.latitude)
) AS distance_meters'),)
->whereNotIn('users.id', $shownUserIds)
->where('users.status', 'active') // 活跃用户
->where('users.id', '!=', auth()->id()) // 排除自己
->whereRaw('ST_Distance_Sphere(POINT(?, ?), POINT(users.longitude, users.latitude)) <= ?', [
$currentUserLng, $currentUserLat,
$currentUserLng, $currentUserLat,
50000 // 50km 范围内（单位：米）
])
->orderBy('distance_meters', 'asc') // 优先返回最近的
->limit(1)
->first([
'id', 'name', 'age', 'bio', 'latitude', 'longitude'
]);
if ($nextUser) {
// 将该用户 ID 加入已展示集合（缓存 + 可选持久化）
$newShownIds = array_merge($shownUserIds, [$nextUser->id]);
Cache::put("user_".auth()->id()."_shown_ids", $newShownIds, 3600); // 缓存 1 小时
}⚠️ 重要注意事项：
- 性能优化：为 latitude 和 longitude 字段建立复合空间索引（如 ADD SPATIAL INDEX idx_location (location_point)），或使用 POINT 类型字段存储位置。
- 缓存策略：$shownUserIds 强烈建议使用 Redis 存储（支持 Set 结构自动去重），而非每次查数据库；超时时间需权衡内存占用与数据新鲜度。
- 兜底机制：当无符合条件用户时（如 $nextUser === null），应清空缓存或切换至全局随机池（inRandomOrder()）作为降级方案，避免接口阻塞。
- 并发安全：若高并发下多个请求几乎同时获取“下一个用户”，需加分布式锁（如 Redis Lock）或采用数据库 SELECT ... FOR UPDATE（慎用，影响性能）。
? 替代思路：伪随机轮询（适用于冷启动或低精度场景）
当地理精度非首要目标，或初期用户密度较低时，可简化为带排除的随机选取（如原答案所提）：
$nextUser = User::whereNotIn('id', $shownUserIds)
->where('status', 'active')
->where('id', '!=', auth()->id())
->inRandomOrder()
->first();⚠️ 注意：inRandomOrder() 在大数据量表上性能较差（MySQL 需 ORDER BY RAND() 全表扫描），仅建议用于万级以内用户或作为地理排序的补充兜底。
✅ 总结
真正健壮的“Tinder 式单用户分发”不是单纯的技术技巧，而是业务规则（距离/活跃/兴趣）、数据结构（空间索引/缓存模型）与工程实践（幂等性/降级/并发控制）的协同结果。推荐以地理距离排序为主干，Redis 缓存已展示 ID 为支撑，辅以合理的超时与降级策略，即可在 Laravel 8 中稳定支撑高可用约会服务。
