Flutter从Firebase Realtime Database匹配随机用户方案咨询

你提到的数据库结构参考如下：

待匹配用户列表检索语法 #

以下以Web端JS SDK v9版本为例，其他端SDK逻辑一致，仅API写法略有差异：
注意：匹配逻辑强烈建议部署在Firebase Cloud Functions中执行，不要直接在客户端拉取全量待匹配用户，避免数据泄露和并发冲突

import { getDatabase, ref, query, orderByChild, equalTo, get } from "firebase/database";
const db = getDatabase();

/**
 * 获取所有主动寻找匹配的在线用户
 * @param {string} currentUserId 当前发起匹配的用户ID，用于排除自身
 * @returns {Array} 待匹配用户列表
 */
async function fetchWaitingUsers(currentUserId) {
  const usersRef = ref(db, 'users');
  // 筛选标记为正在匹配状态的用户，假设你用isSearching: true标记待匹配状态
  const searchQuery = query(
    usersRef,
    orderByChild('isSearching'),
    equalTo(true)
  );
  const snapshot = await get(searchQuery);
  if (!snapshot.exists()) return [];
  // 转换为数组格式，过滤掉当前用户自身
  return Object.entries(snapshot.val())
    .filter(([uid]) => uid !== currentUserId)
    .map(([uid, userInfo]) => ({ uid, ...userInfo }));
}

偏好校验+随机配对逻辑 #

1. 双向偏好过滤 #

必须做双向偏好校验，避免出现A符合B的偏好但B不符合A的偏好，导致匹配后秒退的无效匹配：

/**
 * 从待匹配池中筛选出符合双向偏好的候选用户
 * @param {object} currentUser 当前用户数据
 * @param {Array} waitingUsers 待匹配用户池
 * @returns {Array} 符合匹配要求的候选列表
 */
function filterValidCandidates(currentUser, waitingUsers) {
  return waitingUsers.filter(candidate => {
    // 替换成你实际的偏好规则，以下为常见示例
    // 正向校验：候选符合当前用户的偏好
    const matchMyPrefer = 
      currentUser.preferGender.includes(candidate.gender) &&
      candidate.age >= currentUser.preferAge[0] &&
      candidate.age <= currentUser.preferAge[1];
    // 反向校验：当前用户符合候选的偏好
    const matchCandidatePrefer =
      candidate.preferGender.includes(currentUser.gender) &&
      currentUser.age >= candidate.preferAge[0] &&
      currentUser.age <= candidate.preferAge[1];
    
    return matchMyPrefer && matchCandidatePrefer;
  });
}

2. 随机选择+原子性配对 #

必须用原子更新/事务操作完成配对状态修改，避免高并发下同一个用户被同时匹配给多个人：

import { ref as dbRef, update } from "firebase/database";

/**
 * 完成两个用户的配对，原子更新状态
 * @param {object} userA 匹配用户A
 * @param {object} userB 匹配用户B
 * @returns {string} 匹配会话ID
 */
async function createMatchPair(userA, userB) {
  const matchId = `match_${Date.now()}_${Math.random().toString(36).slice(2, 8)}`;
  const rootRef = dbRef(db, '/');
  // 批量原子更新：把两个用户的匹配状态改为已匹配，写入匹配会话数据
  const updatePayload = {
    [`users/${userA.uid}/isSearching`]: false,
    [`users/${userA.uid}/currentMatchId`]: matchId,
    [`users/${userB.uid}/isSearching`]: false,
    [`users/${userB.uid}/currentMatchId`]: matchId,
    [`matches/${matchId}`]: {
      members: [userA.uid, userB.uid],
      createTime: Date.now()
    }
  };
  await update(rootRef, updatePayload);
  return matchId;
}

// 从候选列表随机抽取匹配对象
function pickRandomCandidate(candidateList) {
  if (candidateList.length === 0) return null;
  const randomIdx = Math.floor(Math.random() * candidateList.length);
  return candidateList[randomIdx];
}

实现避坑建议 #

• 客户端仅需要在用户点击开始匹配时，把自身节点下的isSearching字段设为true，监听自身的currentMatchId字段变化即可，不要给客户端开放其他用户节点的读权限。
• 增加超时清理逻辑：用户离线、切后台超过30秒未响应时，自动把对应isSearching字段设为false，避免匹配到无效用户。
• 可优化随机权重：给等待匹配时间更长的用户设置更高的选中权重，减少用户等待时长，避免老用户长期匹配不到。
• 匹配逻辑加锁：云函数执行匹配时，判断到用户的isSearching已经变为false时直接终止匹配流程，避免重复配对。

内容的提问来源于stack exchange，提问作者Jayleen45