客户端唯一ID生成策略详解

客户端唯一ID：为什么需要它

你在刷短视频时，有没有发现退出账号再登录，浏览记录、点赞数据还能对上？或者换了个手机，同步起来也挺顺滑？这背后少不了一个关键角色——客户端唯一ID。

这个ID就像设备的“身份证”，不依赖用户名或手机号，哪怕用户没登录，系统也能靠它识别你是谁。广告点击追踪、行为分析、防刷机制，都指着它干活。

常见生成方式有哪些

最简单的办法是用随机字符串。比如在 JavaScript 里：

function generateId() {
  return Math.random().toString(36).substr(2, 9);
}

看起来凑合，但问题不少。重启应用可能变，不同浏览器也不一样，甚至同一台设备两次生成的ID都对不上。

于是有人想到用设备信息拼接：用户代理、屏幕分辨率、时区、语言这些。组合起来当指纹，也算稳定。

const fingerprint = navigator.userAgent + 
  screen.width + screen.height + 
  Intl.DateTimeFormat().resolvedOptions().timeZone;

问题是，这些信息太容易变。换个浏览器字体，升级系统，指纹就变了。而且隐私政策越来越严，有些信息根本拿不到。

本地存储的实用方案

现在主流做法是：第一次访问时生成一个ID，存在 localStorage 或 Cookie 里。下次打开直接读取。

let clientId = localStorage.getItem('client_id');
if (!clientId) {
  clientId = 'cid_' + Date.now() + '_' + Math.random().toString(36).substr(2, 6);
  localStorage.setItem('client_id', clientId);
}

这招简单有效，大多数场景够用。但用户清缓存就没了，跨浏览器也不共享。

如果想更持久，可以试试 IndexedDB，或者结合 service worker 做点小技巧，不过复杂度立马往上翻。

移动端的特殊处理

在App里情况稍好。iOS 可以用 identifierForVendor（IDFV），Android 有 Settings.Secure.ANDROID_ID。这些系统级标识符稳定性高，只要不重装应用就不变。

但注意，root 过的安卓机可能篡改 ANDROID_ID，模拟器更是随便伪造。做反作弊的得留个心眼。

还有些团队会把多种来源组合成复合ID：优先用系统ID，没有就降级到存储方案，再加个随机后备。这样容错性强一点。

隐私与合规的边界

欧盟GDPR、中国个人信息保护法都盯着这类标识符。如果你的ID能关联到具体个人，哪怕间接的，也算个人信息。

所以别瞎传。该加密加密，该匿名化匿名化。用户不同意追踪时，干脆别生成。

有些产品选择在用户首次交互时才生成ID，比如点过“同意使用统计”再动手。既合规，又避免一上来就被拦截。

ID本身也别带敏感信息。曾经有公司把IMEI或MAC地址塞进ID，结果被通报下架。这种老黄历早该翻篇了。

实际落地的小建议

上线前多测几轮。模拟清除缓存、无痕模式、多标签页并发访问，看看ID会不会莫名其妙重置。

加上日志监控。某天突然大量新ID涌入，可能是代码出了岔子，也可能是爬虫在扫你。

最后一点：别追求绝对唯一。目标不是造个宇宙独一份的ID，而是满足业务周期内的可识别性。够用就好，别给自己挖坑。