一位话事人反馈：「我点 lead 列表 / F5 刷新经常卡 1-3 秒，连 SSH 终端都跟着卡。 明明这台服务器 31GB 内存才用 9GB，怎么会卡？」

排查结论：不是内存不够，也不是网络问题。是 28 个 WA 同时跑 chromium 浏览器， 125 个 chrome 进程互相挤 CPU 调度。

📍 三层优化（全部今天 ship）

📍 实测（重启验证）

冷号代价：销售给冷号发首条消息会等 30-60 秒（chromium 启动），retry 队列兜底不会丢消息。冷号定义=过去 7 天发送 < 10 条。

一位搞钱的反馈：「我重新扫码后，那些之前因为'WA Session 过期'变成失联的 lead，岂不是浪费了？」

你说得对。今天加了双轨复活机制：

🅰️ 自动模式（你不用做任何事）

• WA 号扫码 → 系统自动找出该号过去 3 天因 session 过期失联的 lead
• 自动改回"待分配"，重新发送
• 限速：每号每小时最多 10 条（防一次性触发反爬封号）

🅱️ 手动模式（WA 管理页）

每个号的卡片上多了一个绿色按钮，N 是该号可救的数量。

点一下"🔄 复活失联 15" → 弹确认 → 15 条 lead 全部回到待分配池等重发。

📍 救哪些 lead？

• ✅ lost_reason=session_expired 且 ≤ 3 天内的
• ❌ unregistered（号没注册 WA）— 救了也发不出
• ❌ no_lid（协议层无解）— 救了也发不出
• ❌ dead_form（表单已删除）— lead 来源没了
• ❌ > 3 天前的失联 — 防止给客户发"上周的广告响应"

查 lead 时顺手发现的 3 个小坑，今天一起修了。

1️⃣ lead 姓名超长撑破表格

lead #1868 的名字太长，整个 lead 管理页排版崩了 — 列被推到屏幕外。 现在统一截断 30 字 + ...，鼠标悬停看完整名字。

2️⃣ 联络日志同样问题

联络日志页的 "Lead 姓名" 列也被同一类长名字撑破。同样修。

3️⃣ BWR G6 表单 6 条 lead 卡 "policy 阻挡"

在"未分配"页面看到 lead #1935-#1940 显示 🟡 policy 阻挡，无法分配。

查到这表单当初被运营标记 intentional_null（"故意收无效 lead 不分配"）， 原因是它只收 phone 不收 name。但实际业务里销售只用 phone 也能联系，已把它改回 pending， 6 条 lead 立刻进入正常分配流程，未来该表单 lead 也会自动分配。

👤 搞钱的（销售）

• ✅ 什么都不用做。F5 后台应该明显不卡了
• ✅ 扫码后系统会自动救老 lead（3 天内 session 过期失联的）
• ⚠️ 如果你的号是冷号（一周没发几条），点"立即发送"会等 30-60 秒（chromium 启动），是正常现象 — retry 队列兜底不会丢消息

🎯 烧钱的（广告投手）

• 👀 注意 WA 管理页的 "🔄 复活失联 N" 绿色按钮
• 看到大数字（比如 > 10）就点一下批量复活，把 sales 已扫码但还没自动救完的补上
• 如果建了"只收 phone"的表单，系统现在会正常分配，不再卡 policy 阻挡

👑 话事人（你）

• ✅ 服务器卡顿大幅缓解（cs 17000 → 7130，进入流畅区间）
• ⚡ 明天评估：要不要把 lead-system 从 chromium 路线迁到 Baileys（彻底告别 chromium 进程风暴 · 资源砍 12 倍）
• ⚠️ 致命提醒：lead-system 跟"不求人 SCRM"长期跑同一台服务器有客户体验风险，Baileys 决策时一并考虑

一位搞钱的反馈：「我的 WA 管理页显示号码全部"✅ 活跃"，但 Lead 详情却写 "WA Session 过期，已跳过" — 我该信哪边？」

排查结论：两边都没说谎，但 WA 管理页 UI 长期没把"运行时真相"展示给你。我们今天彻底改了。 更进一步发现整个 WA 系统架构有错配，一并修了。

现在登录 WA 管理页能看到这些（下面所有"图"都是真实 UI 复刻）：

📍 顶部全局告警条

登录最先看到 — 一眼知道有几个号需要扫码 + 全局工作量。

📍 卡片红色告警条

每个出问题的号顶部会有醒目的红条 + 损失统计 + 一键修复按钮。

📍 工作流可见 + 点击穿透

每个号都有这一行小卡片 — 三个数字都可点击，点哪个跳到对应详情。

📍 详情 modal — 失联原因聚合 + 一键重激活

点"📋 详情"会展开聚合数据。如果失联是因为 session 过期，下面会出现"重激活"按钮。

排查发现以前的设计是「内存少所以让 WA 闲置 1 小时就关掉」。 但这台服务器有 31GB 内存，实际只用 109MB。 结果反过来变成「经常关 → 经常重启 → 容易失败 → session 被 WA 服务端嫌长期不动给禁了」。

今天还修了一批权限/安全洞，搞钱的不用关心，话事人/烧钱的看一眼放心：

• 批 1 · sales_rep 之前在某些 API 能看到不属于自己范围的数据 — 已收紧（4 处）
• 批 2-3 · webhook 签名验证之前形同虚设（缺 header 即绕过）— 现在强制要求 + 用原始字节比对 + 时序安全比较
• 批 2-3 · webhook 路径加独立 rate limiter（30 req/min/IP）
• 批 4 · 导出CSV / 同步表单按钮对 sales_rep 隐藏（之前点了会 403 误导）
• 批 4 · webhook 进来的 lead 之前一直没正确关联到 FB 账号（dashboard 统计错位）— 修了 lookup 字段
• 共 4 批 · 5 个 commit · 全 push 到 GitHub

所有改动 6 个 commit 已 push 到 GitHub：

• 0d6d066 安全审计批 1（跨范围数据泄露）
• 08a3d4c 安全审计批 2+3（webhook 签名严格化 + 模版 UI）
• c027511 安全审计批 4（UI 显隐 + page_id lookup）
• d74d20e WA 管理页大改造（红条 / 工作流 / 一键重连）
• 0c99192 系统稳定性（idle 8h / keepalive / pm2 8GB / batch reactivate）
• 1b08c34 系统公告页 v1（后续重构成钻取式）

如果你看到这页之后还有「lead 失联但 WA 看起来活跃」的情况，请截图反馈。 T+7 (5-06) 我们会主动回头核对数据 — 应该看到失联率从 30%+ 回到个位数。