如何在Firebase Database中检查值存在并修复点赞重复问题

• likedBy节点存储结构与校验逻辑不匹配
  你新增点赞时，是用点赞用户数的自增数字作为likedBy的子节点key，值为当前用户名。但你判断用户是否已点赞时，调用的是dataSnapshot.child("likedBy").hasChild(currentUser[0])，本质是判断likedBy下是否存在以用户名为key的子节点，和实际存储结构完全不符，所以liked变量永远为false，点赞按钮永远不会切换为绿色选中态。
• 重复点赞逻辑校验失效
  因为liked变量始终为false，所有点击事件都会走新增点赞的分支，不会进入取消点赞逻辑，每次点击都会新增一条数字key、值为当前用户名的记录，最终出现多条相同用户名的点赞记录。

1. 修正likedBy节点存储逻辑 #

将likedBy的子节点key改为用户名，值可存true或点赞时间，从根源上避免重复存储，修改点赞分支的对应代码：

// 替换原有用数字序列作为key的代码
dataSnapshot.child("likedBy").child(currentUser[0]).getRef().setValue(true);

修改后你原有的hasChild(currentUser[0])校验逻辑即可正常生效，点赞按钮状态会正确切换。

2. 优化问题匹配逻辑 #

你当前通过问题内容、提问者、点赞数三个字段遍历全量问题节点匹配目标问题，不仅性能极低，而且点赞数是动态变化的，很容易出现匹配失败的情况。建议给每个问题生成唯一ID，所有读写操作直接通过ID定位对应节点，避免遍历全量数据。

3. 其他优化建议 #

• 使用Firebase原子操作更新点赞数：直接读取本地存储的点赞数加减容易出现并发冲突，建议用ServerValue.increment(1)做原子增量，避免多用户同时点赞时计数错误。
• 点击后临时禁用点赞按钮：触发点赞/取消点赞请求后先将按钮设为不可点击，等Firebase操作完成后再恢复可点击状态，避免网络延迟时用户连续点击触发多次重复请求。

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