基于Java、MQTT与Mosquitto的聊天应用联系人同步方案求助

这个问题挺典型的，我之前做即时通讯类项目时也碰到过类似的困境——既要严格保护用户手机号隐私（不能明文传输到服务器），又要准确识别哪些联系人是平台内成员，还得避开“对方不在线就误判”的坑。给你几个经过实际验证的可行方案，你可以根据自己的架构和业务需求选择：

方案1：本地单向哈希+服务器预存映射（首推） #

核心思路是用哈希值替代明文手机号做身份标识，彻底绕开隐私传输问题，同时不受对方在线状态影响：

1. 客户端本地处理：对每个联系人的手机号做加盐单向哈希（比如SHA-256，建议给每个用户分配唯一的本地盐，或者和服务器协商统一盐值，避免彩虹表破解）。
2. 服务器端准备：提前将所有平台用户的手机号用相同的加盐规则哈希，存储哈希值与用户ID的映射表。
3. 同步校验：客户端把所有联系人的哈希值打包发送给服务器，服务器比对后返回匹配的哈希列表，客户端再对应到本地联系人，标记为平台成员。

Java里的哈希实现示例（简化版）：

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;

public class PhoneHashUtil {
    // 建议使用每个用户专属的盐，可存在本地或从服务器获取
    private static final String USER_SALT = "your_unique_user_salt";

    public static String hashPhone(String phoneNumber) throws NoSuchAlgorithmException {
        MessageDigest md = MessageDigest.getInstance("SHA-256");
        md.update((phoneNumber + USER_SALT).getBytes());
        return Base64.getEncoder().encodeToString(md.digest());
    }
}

这种方式完全不涉及明文手机号传输，隐私性拉满，而且不管对方在线与否，都能准确判断是否为平台成员，效率也很高。

方案2：MQTT保留消息优化原思路 #

如果你想沿用MQTT主题探测的方式，可以通过保留消息解决对方不在线的问题：

1. 每个平台用户在自己的专属验证主题（比如/user/verify/{hashed_phone}）上发布一条保留消息，内容可以是自己的用户ID或固定标识。
2. 当你要校验联系人时，订阅对应联系人哈希值的验证主题：
   • 如果收到保留消息，说明对方是平台成员（不管当前在线状态）；
   • 如果订阅后超时未收到任何消息，则判定为非平台成员。
3. 注意事项：用户注销账号时，一定要记得删除对应的保留消息，避免留下无效数据干扰后续判断。

方案3：本地批量哈希+MQTT批量请求（适合实时同步） #

如果需要实时同步新增联系人，可以把多个联系人的哈希值打包成一条MQTT消息发送到服务器的批量校验主题（比如/server/verify/batch），服务器处理后返回匹配结果。这种方式比逐个订阅主题更高效，也同样不涉及明文手机号传输，且不受对方在线状态影响。

额外注意点 #

• 加盐一定要重视：单纯的手机号哈希容易被彩虹表破解，添加用户专属盐或全局盐能大幅提升安全性；
• 哈希值唯一性：确保不同手机号经过哈希后不会碰撞（SHA-256的碰撞概率极低，基本可以忽略）；
• 服务器映射更新：当用户更换手机号时，要及时更新服务器端的哈希-用户ID映射表，避免判断错误。

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