React+Firestore高效过滤屏蔽用户动态：现有实现需优化吗？

当前你在前端拉取所有动态后再过滤屏蔽用户的内容，当动态数量或屏蔽列表变大时，会带来带宽浪费和前端计算压力，这里提供几个更高效的实现方案：

1. 在Firestore查询阶段直接过滤（最优方案） #

把过滤逻辑从前端转移到数据库查询，从根源减少传输的数据量。Firestore支持not-in查询来排除指定用户的动态，但要注意**not-in最多支持10个元素**，所以需要根据屏蔽列表的长度做不同处理：

代码示例： #

const Feed = ({ currentUser }) => {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    let unsubscribe;

    // 无屏蔽用户时，直接查询所有动态
    if (!currentUser?.blockedUsers || currentUser.blockedUsers.length === 0) {
      unsubscribe = firebase.firestore().collection('posts')
        .onSnapshot(snapshot => {
          const allPosts = snapshot.docs.map(doc => ({ id: doc.id, ...doc.data() }));
          setPosts(allPosts);
        });
      return unsubscribe;
    }

    const blockedIds = currentUser.blockedUsers;
    // 拆分屏蔽列表为每10个一组，适配Firestore的not-in限制
    const queryBatches = [];
    for (let i = 0; i < blockedIds.length; i += 10) {
      const batch = blockedIds.slice(i, i + 10);
      queryBatches.push(
        firebase.firestore().collection('posts').where('userId', 'not-in', batch).get()
      );
    }

    // 实时监听动态变化，合并多批次查询结果并去重
    unsubscribe = firebase.firestore().collection('posts')
      .onSnapshot(async () => {
        const snapshots = await Promise.all(queryBatches);
        const postMap = new Map();

        snapshots.forEach(snap => {
          snap.docs.forEach(doc => {
            const post = { id: doc.id, ...doc.data() };
            // 最终二次过滤确保没有漏网之鱼
            if (!blockedIds.includes(post.userId)) {
              postMap.set(post.id, post);
            }
          });
        });

        setPosts(Array.from(postMap.values()));
      });

    return unsubscribe;
  }, [currentUser]);

  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>
          <p>{post.text}</p>
        </div>
      ))}
    </div>
  );
};

这个方案的优势是减少了无用数据的传输，前端不需要处理全量动态，整体性能提升明显。

2. 前端过滤的效率优化（低成本改进） #

如果暂时不想调整查询逻辑，可以优化前端的过滤方式：把屏蔽用户ID数组转为Set，因为Set.has()的查询效率是O(1)，远高于数组includes()的O(n)，尤其是当屏蔽列表较长时效果显著。

代码示例： #

const Feed = ({ currentUser }) => {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    const blockedSet = currentUser.blockedUsers ? new Set(currentUser.blockedUsers) : new Set();
    const unsubscribe = firebase.firestore().collection('posts')
      .onSnapshot(snapshot => {
        const filteredPosts = snapshot.docs
          .map(doc => ({ id: doc.id, ...doc.data() }))
          .filter(post => !blockedSet.has(post.userId));
        
        setPosts(filteredPosts);
      });

    return unsubscribe;
  }, [currentUser]);

  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>
          <p>{post.text}</p>
        </div>
      ))}
    </div>
  );
};

3. 数据结构调整（适配长屏蔽列表场景） #

如果用户的屏蔽列表经常超过10个，当前的子集合存储方式可以保留，但可以结合以下思路优化：

• 不要在用户文档中存储blockedUsers数组，而是通过子集合blockedUsers的查询结果来构建屏蔽ID集合，避免数组长度限制
• 当用户屏蔽/取消屏蔽时，通过Cloud Function同步维护一个反向索引（比如给被屏蔽用户的动态标记，但实现成本较高）

不过大多数场景下，前两种方案已经足够覆盖需求。

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