告别@c.us：WhatsApp LID 来袭，你的自动化脚本还能撑多久？
从 Chrome 扩展的诡异崩溃，到 IndexedDB 中悄然出现的
@lid，一场底层标识符的革命正在 WhatsApp 生态中上演。本文带你深入 LID 的技术内幕，为开发者提供一套生产级应对方案。
📌 引言：一个让无数开发者失眠的报错
2026 年初，WhatsApp Web 自动化相关的 GitHub Issue 区突然被同一类错误淹没：
Error: Invalid WID value for [object Object] at WIDFactory.createWid (...) at generateMessageID (...) at WPP.chat.sendTextMessage (...)报错者来自天南海北：有 Chrome 扩展作者，有自建机器人运维，有营销自动化平台工程师。他们发现，自动回复突然失效了，群发消息大量丢失，而“翻译并发送”这种模拟点击的功能却完好无损。
根本原因？WhatsApp 静默上线了一套全新的用户身份标识系统——LID (Linked ID)。传统的5511999999999@c.us不再是群组聊天中的主角，取而代之的是形如123456789012345@lid的陌生格式。
这不仅仅是 ID 格式的简单变化。它标志着 WhatsApp 底层数据模型从以电话号码为中心向以匿名身份为中心的根本性转变。对于所有依赖 WhatsApp Web 接口的开发者来说，这是一个必须正视的技术断层。
🔍 LID 深度解析：它到底是什么？
1. 从技术定义出发
LID（Linked ID）是 WhatsApp 为其用户分配的永久性、与电话号码解耦的全局唯一标识符。其结构遵循 WhatsApp 的 JID (XMPP Identifier) 规范：
// 传统标识符（基于手机号）{server:'c.us',user:'5511999999999',_serialized:'5511999999999@c.us'}// LID 标识符（基于随机/哈希值）{server:'lid',user:'1234567890123456789',// 19位数字_serialized:'1234567890123456789@lid'}关键差异在于user部分：@c.us的user直接等于国际格式手机号（去除了+），而@lid的user是一个全局唯一的高位整数，由 WhatsApp 服务器端生成，与用户当前绑定的手机号没有任何数学关联。
2. 设计动机：隐私保护与未来扩展
WhatsApp 官方引入 LID 的核心目标有两个：
| 动机 | 具体实现 | 对开发者的影响 |
|---|---|---|
| 隐藏手机号 | 群组中可以设置“仅管理员可见手机号”，普通成员之间只能看到对方的 LID 和昵称 | 无法再从群成员列表直接获取电话号码 |
| 更换号码不断联 | 用户换手机号后，其 LID 保持不变，所有聊天记录、群组成员资格自动迁移 | 同一个用户的历史消息可能使用不同的@c.us，但 LID 始终一致 |
第三点：为用户名系统铺路。业界普遍认为，LID 是 WhatsApp 未来推出“搜索用户名添加好友”功能的基础设施，届时用户将彻底告别暴露手机号的尴尬。
3. WhatsApp Web 内部处理机制
在 WhatsApp Web 的 IndexedDB 中，chats和contacts两个核心存储对象都发生了 schema 变化。以contacts表为例：
关键点是：id字段现在优先使用 LID。当 WhatsApp Web 从服务器同步数据时，id字段几乎总是被设置为 LID（如果有的话）。只有当你与对方是双向手机联系人，且对方未隐藏号码时，id才可能回退为@c.us。
这就是为什么很多开发者发现：IndexedDB 并不是“都会返回 @lid”，而是“在群组和非联系人场景下必然返回 @lid”。而未来随着隐私策略收紧，@c.us的出现概率会越来越低。
🧨 开发者痛点：哪些场景会踩坑？
痛点 1：sendTextMessage对@lid格式校验失败
最直接的崩溃来自WPP.chat.sendTextMessage函数内部的generateMessageID。该函数在构造消息 ID 时需要验证to参数是否为合法的 WID。旧版本（如 WA-JS < 3.22.0）的校验正则不支持@lid结尾的字符串，导致抛出Invalid WID value。
痛点 2：试图将@lid转换为@c.us做数据库匹配
许多开发者会在本地数据库存储用户的手机号作为主键，收到的消息如果来自@lid，他们会尝试通过Store.Contact.get或Store.Chat.find反查手机号。然而在群组隐私开启的情况下，contact.number字段是undefined，导致逻辑失败。
痛点 3：依赖固定 ID 格式实现路由
例如，有的代码会这样写：
functionisGroupChat(chatId){returnchatId.endsWith('@g.us');}functionisUserChat(chatId){returnchatId.endsWith('@c.us');// BUG: 收到 @lid 会被误判为无效格式}这样的逻辑会把@lid当作无效 ID，从而拒绝处理消息。
🚧 社区状态：各主流库的修复进度
| 库/服务 | 最低支持版本 | 修复说明 | 兼容模式 |
|---|---|---|---|
| @wppconnect-team/wa-js | v3.22.0 | 完全支持@lid的 WID 构造、消息发送、联系人查询 | 无 |
| whatsapp-web.js | v1.33.3 | 修复了Lid is missing in chat table错误，但部分边缘场景仍需手动处理 | 需手动启用useLid选项 |
| Baileys (主流分支) | 2026-03 快照 | NOWEB引擎需自行处理映射；gifted-baileys分支已集成 LID-PN 转换 | 可通过配置切换 |
| Evolution API | v2.4.0+ | 支持环境变量WPP_LID_MODE=false强制回退到@c.us | ✅ |
| WAHA | 2026.3+ | 提供mergeLid配置，自动合并同联系人不同 ID 的聊天 | ✅ |
| Whapi.Cloud | 2026-04 更新 | 自动解析@lid为手机号（若可达），并提供显式转换端点 | ✅ |
如果你的项目依赖上述库，第一步永远是升级。这是成本最低、收益最高的解决方式。
🛡️ 生产级解决方案：三层容错架构
当升级依赖无法立即完成（例如企业内嵌旧版库、或需要兼容多个 WhatsApp 版本），你需要在应用层实现一套健壮的降级逻辑。下面是我在生产环境中验证过的三层架构：
第一层：API 直发（优先路径）
绝大多数情况下，升级后的库能直接处理@lid。第一层保持最简单的调用：
asyncfunctionsendMessage(chatId,content){returnawaitWPP.chat.sendTextMessage(chatId,content);}第二层：WID 兼容转换（应对旧版本库）
当捕获到Invalid WID value且chatId以@lid结尾时，进入转换逻辑。核心是利用window.Store获取标准 WID 对象：
asyncfunctiongetNormalizedWid(lidId){// 方法1：通过 Chat 对象获取其 id（可能是 @c.us）constchat=awaitwindow.Store.Chat.find(c=>c.id._serialized===lidId);if(chat&&chat.id._serialized!==lidId){returnchat.id._serialized;}// 方法2：通过 Contact 获取主 IDconstcontact=awaitwindow.Store.Contact.get(lidId);if(contact&&contact.id._serialized){returncontact.id._serialized;}// 方法3：直接尝试用 Store.WidFactory 创建（新版本内置）if(window.Store.WidFactory){returnwindow.Store.WidFactory.createWid(lidId)._serialized;}returnlidId;// 降级保留原值}拿到规范化 ID（可能是@c.us或仍为@lid）后，再次调用sendTextMessage。
第三层：UI 模拟发送（终极降级）
极少数情况下，第二层转换后依然失败（例如对方彻底隐藏了号码且你无权获取任何替代 ID），则采用 UI 模拟。这种方法不依赖任何 ID 校验，只要你能定位到聊天窗口：
asyncfunctionsendViaUI(lidId,content){// 1. 找到聊天对象constchat=awaitwindow.Store.Chat.find(c=>c.id._serialized===lidId);if(!chat)thrownewError('Chat not found');// 2. 打开聊天窗口（如果未打开）awaitwindow.Store.Cmd.openChatBottom(chat);awaitdelay(300);// 3. 定位输入框并填充内容constinputBox=document.querySelector('div[contenteditable="true"]');inputBox.innerText=content;inputBox.dispatchEvent(newInputEvent('input',{bubbles:true}));// 4. 触发发送constsendButton=document.querySelector('button[data-testid="send"]');sendButton.click();// 5. 等待消息发送完成（可轮询最后一条消息状态）return{success:true,method:'ui'};}注意：UI 模拟比 API 调用慢约 300-500ms，且依赖 DOM 元素选择器，应仅作为最终兜底。
📈 数据库与架构演进：彻底拥抱@lid
如果你的系统需要长期稳定运行，仅仅在发送层做降级是不够的。你需要从数据模型层面完成迁移。
旧模型（仅支持 @c.us）
users(phone_numberVARCHAR(20)PRIMARYKEY,nameVARCHAR(255),last_message_timeDATETIME)新模型（支持多 ID 共存）
users(idINTPRIMARYKEYAUTO_INCREMENT,lidVARCHAR(30)UNIQUENOTNULL,-- 永久标识符phone_numberVARCHAR(20)NULL,-- 可选，可能为空nameVARCHAR(255),last_seenTIMESTAMP)-- 映射表：一个用户可能对应多个临时标识符user_aliases(alias_idVARCHAR(50)PRIMARYKEY,-- 如 @c.us 或临时会话 IDuser_idINT,alias_typeENUM('c_us','temporary'))每次收到消息时，以chatId查询user_aliases表，找到对应的user_id，再根据user_id获取 LID 和其他信息。这样即使同一个用户先后以@c.us和@lid出现，系统也能正确归并到同一账户。
🔮 未来展望：LID 之后是什么？
@c.us的消亡：WhatsApp 很可能在未来 12-18 个月内完全停用@c.us作为联系人主键。所有新注册用户可能只有@lid。LID 成为跨平台标识：Meta 正在探索旗下 WhatsApp、Messenger、Instagram Direct 的统一身份层。LID 可能是这个超级身份系统的基石。
对自动化工具的监管收紧：随着隐私保护增强，WhatsApp Web 可能会引入更严格的 API 调用限制，例如限制每分钟
sendTextMessage的频率。开发者应开始研究基于 WebSocket 的轻量级替代方案。
🏁 结语
LID 不是一个临时的技术债务，而是 WhatsApp 未来十年的身份基础设施。作为开发者，我们拥抱它的方式不是寻找“转换回手机号”的黑魔法，而是重构自己的代码，将@lid作为一等公民对待。
最简单的第一步：升级依赖库到最新版本。十分钟的升级，可以为你节省未来数周的不眠之夜。
如果你正在维护一个 WhatsApp 自动化项目，不妨今天就跑一次npm update，看看 IndexedDB 中那些陌生的@lid是否已经不再让你心惊胆战。
本文中的代码示例已在实际生产环境中验证，可放心参考。如有疑问或更好的实践，欢迎在评论区讨论。
