Firebase Cloud Messaging（FCM）是目前使用最广泛的移动端推送服务之一，但很多接入它的团队都会遇到一个共同的问题：推送消息到底该用什么作为唯一ID？FCM下发的消息体里并没有一个统一的、可直接用于业务去重的ID字段，如果发送端不主动设计，客户端就可能出现重复弹通知、通知无法覆盖更新等问题。本文从服务端和客户端两个视角，讨论几种生成唯一ID的实用方案。
为什么FCM推送需要自己生成唯一ID
首先要明确一点，FCM的消息结构中虽然有message_id这样的字段，但它是FCM内部用于消息投递追踪的标识，语义上更接近"投递ID"而不是"业务ID"。同一条业务消息如果重发，message_id会变化；而且这个字段在客户端SDK中并不总是稳定可取。所以在业务层面，我们通常不能直接依赖它做去重或幂等判断。
第二个原因是通知覆盖的需求。很多App有"新消息数"通知或聊天消息通知，这类通知不能无限叠加，而是希望同一条会话的新消息覆盖旧通知。要实现覆盖，Android端必须给Notification设置相同的id。这个id从哪来？最自然的做法就是服务端在下发推送时生成一个业务唯一ID，客户端拿到后直接使用，这样两端语义一致，排查问题也方便。
第三个原因是数据统计与回溯。给每条推送分配唯一ID后，可以在点击通知上报时带上这个ID，服务端就能精确统计每条推送的到达率、点击率，甚至做A/B实验分组，这是没有ID的消息无法做到的。
服务端生成唯一ID的几种方案
最直接的方案是使用UUID。Node.js环境内置了crypto模块，可以直接生成UUID v4：
const crypto = require('crypto');
// 生成业务唯一ID
const messageId = crypto.randomUUID();
console.log(messageId); // 例如 5f8b3c2e-1a4d-4e6f-9b7a-2c3d4e5f6a7b
// 下发FCM推送时携带唯一ID
const message = {
token: deviceToken,
data: {
messageId: messageId,
type: 'chat',
conversationId: 'conv_10086',
content: '你有一条新消息'
},
notification: {
title: '新消息',
body: '你有一条新消息'
}
};
admin.messaging().send(message);UUID的优点是生成简单、碰撞概率几乎为零、不依赖任何第三方库。缺点是长度有36个字符，放在data payload里会增加消息体积，而且对人类不友好，日志排查时不便阅读。如果对长度敏感，可以自己实现一个短ID方案，比如把时间戳与随机数拼接：
// 时间戳 + 随机数构成的短ID，排序友好且长度可控
function generateShortId() {
const ts = Date.now().toString(36);
const rand = crypto.randomBytes(4).toString('hex');
return `${ts}-${rand}`;
}
console.log(generateShortId()); // 例如 ly3k9x-a1b2c3d4这种短ID保留了时间信息，天然按时间排序，非常适合做消息列表展示。另一种常见做法是使用nanoid库，它默认21个字符，碰撞概率与UUID相当，且可以自定义字符集排除易混淆字符。如果推送量非常大（每天千万级以上），还可以考虑雪花算法，它把时间戳、机器ID、序列号编码在一个64位整数中，生成效率高且趋势递增，但需要自行解决多实例的机器ID分配问题。
需要注意的一个细节是：如果业务本身已经有主键（比如订单号、消息表的自增ID），强烈建议直接使用业务主键作为推送唯一ID，而不是另造一个。这样推送与业务数据天然关联，客户端点击通知后可以直接用这个ID请求详情，省去一层映射。
客户端如何利用唯一ID实现去重与通知覆盖
服务端生成了ID，客户端要正确消费它。Android端收到FCM消息后，在onMessageReceived回调中取出data里的messageId，用它作为NotificationManager的id：
public class MyFirebaseMessagingService extends FirebaseMessagingService {
@Override
public void onMessageReceived(RemoteMessage remoteMessage) {
String messageId = remoteMessage.getData().get("messageId");
String convId = remoteMessage.getData().get("conversationId");
NotificationCompat.Builder builder = new NotificationCompat.Builder(this, "chat")
.setSmallIcon(R.drawable.ic_notify)
.setContentTitle(remoteMessage.getNotification().getTitle())
.setContentText(remoteMessage.getNotification().getBody())
.setAutoCancel(true);
NotificationManager manager =
(NotificationManager) getSystemService(NOTIFICATION_SERVICE);
// 同一会话使用同一个id，新消息自动覆盖旧通知
int notifyId = convId.hashCode();
manager.notify(notifyId, builder.build());
}
}上面的例子展示了一个技巧：对于需要覆盖的会话类通知，不要直接用messageId做notifyId（每条消息的ID都不同，无法覆盖），而是用conversationId的hash值作为notifyId，实现同一会话的通知始终只有一条。而messageId则用于另一个用途——去重和上报。
去重的实现思路是维护一个最近处理过的messageId集合。由于FCM在某些情况下可能重复投递（例如设备网络抖动导致ACK丢失），客户端收到消息后先查库或查内存缓存，如果该ID已处理过就直接丢弃。存储可以用Room数据库或SharedPreferences保存最近几百条ID，按LRU淘汰即可。点击通知上报埋点时同样携带messageId，服务端就能把点击事件与下发记录精确关联起来。
iOS端略有不同，APNs的通知由系统展示，客户端代码无法控制通知ID，覆盖逻辑由notification的thread-id控制：在FCM的payload中设置apns-collapse-id，相同值的新通知会自动替换旧通知。因此iOS端只需要在服务端下发时把conversationId填入collapseId字段即可，无需客户端额外处理。
方案对比与选型建议
把上述几种ID方案做个简单对比：
| 方案 | 长度 | 有序性 | 依赖 | 适用场景 |
|---|---|---|---|---|
| UUID v4 | 36字符 | 无 | 无 | 通用，推送量中小 |
| 时间戳+随机数短ID | 约16字符 | 有 | 无 | 需要按时间排序展示 |
| nanoid | 21字符 | 无 | 第三方库 | 追求短且低碰撞 |
| 雪花算法 | Long型 | 严格递增 | 机器ID分配 | 超大规模推送系统 |
| 业务主键 | 不定 | 取决于业务 | 无 | 推送与业务强关联时首选 |
选型上给出几条实用建议：第一，如果业务消息本身有主键，永远优先用业务主键；第二，没有主键时，中小规模用UUID或短ID即可，不必过度设计；第三，需要覆盖更新的会话通知，记得把会话维度ID（conversationId）单独下发，Android端用它做notifyId，iOS端用它做collapseId；第四，messageId无论用哪种方案生成，都要保证它在重试重发时保持不变，也就是说ID应该在业务落库时生成，而不是在调用FCM接口时临时生成，否则服务重发会导致客户端认为是新消息。
最后提醒一个容易踩的坑：不要用时间戳直接做唯一ID。并发场景下两条消息在同一毫秒内生成，时间戳完全相同，会导致去重误判。除非在时间戳后面拼接随机数或序列号，否则纯时间戳不具备唯一性。把唯一ID的设计放在接入FCM的初期就规划好，比后期补救要省力得多。
Firebase push唯一IDID生成修改时间：2026-09-04 14:22:51