LINE Rich Menu Insights 是分析工具，不是入站路由器
7 月 1 日，LINE 宣布通过 Messaging API 创建的 rich menu 已经可以读取统计数据，包括展示次数、点击次数和按天聚合的洞察数据。再往前一个月，LINE 也确认了同一产品表面上的另一个变化：从 2026 年 5 月 26 日起，Get rich menu list 端点限流从每秒 2000 次调整为每秒 10 次。
如果把这两件事当作分析和配置更新来看，它们都很合理。产品团队需要知道哪个 rich menu 区域被点击更多，运营团队需要审计当前发布的是哪套菜单。这些流程都不应该跑在客服消息处理的关键路径里。真正的风险，是小团队把 LINE 官方 Messaging API 当成实时路由层，然后围绕并不适合逐条消息决策的端点写轮询。
如果你的目标是接收 LINE 消息，把它们送进 Slack、CRM 或客服队列，并且之后还要接入 WhatsApp 或 Zalo，架构上应该拆成两个循环：一个慢速的 LINE 官方分析循环，一个事件驱动的入站会话循环。
LINE 具体变了什么
7 月 1 日的更新新增了两个官方 rich menu 洞察端点：Get rich menu insight totals 和 Get rich menu insight by day。以前，通过 Messaging API 创建的 rich menu 无法用同样方式读取这些统计，只能在 LINE Official Account Manager 里查看对应能力。现在，使用 Messaging API 创建菜单的团队可以直接拉取报表数据。
5 月 26 日的更新更偏工程运维。LINE 将 Get rich menu list 的限流从每秒 2000 次改成每秒 10 次，并说明这次通知中没有调整其他端点的限流。
重点不是每秒 10 次够不够你的后台页面使用。大多数情况下是够的。重点是 rich menu 元数据已经很明确地属于缓存配置，而不是高频依赖。如果你的应用每收到一条用户消息都去检查 rich menu 状态，这个设计方向就是反的。
三个循环，三种速度
LINE 客服系统经常把三类问题混在一起，但它们不应该共享同一个时钟。
分析循环。 产品和市场团队读取 rich menu 展示量和每日点击量。它可以每小时或每天跑一次，可以失败后重试，也可以接受延迟，因为它回答的是“昨天哪个菜单入口点击更多”。
配置循环。 工程侧读取当前 rich menu 列表，保存菜单 ID，在菜单变化时更新内部状态。它应该被缓存。新的 10 rps 限流提醒我们，配置读取不应出现在消息热路径里。
入站路由循环。 客服侧需要立刻知道客户刚刚发了消息、哪个账号收到了消息、发送者是谁、文本或媒体是什么、应该路由到哪里。这个循环应该由事件驱动，不应该等待 rich menu list、insight 或报表刷新。
UnifyPort 放在第三个循环里。它不替代 LINE 官方分析端点，而是为 LINE、WhatsApp、Telegram、TikTok、Zalo 和 X 提供 webhook-first 的入站层，并在多个平台之间使用同一套标准事件结构。
入站路径应该怎么走
使用 UnifyPort 时，一条 LINE 消息会作为 message.received webhook 事件到达你的服务端。投递方式是对你的端点发起 HTTP POST。事件信封在支持的平台之间保持一致：id、type、provider、account_id、occurred_at 和 data。
一条 LINE 入站文本消息可以按下面的结构处理：
{
"id": "evt_4f1b9c2a70",
"type": "message.received",
"provider": "line",
"account_id": "acc_8c21d0",
"occurred_at": "2026-07-04T02:18:30Z",
"data": {
"conversation": { "id": "U4af2c891", "type": "user" },
"sender": { "id": "U4af2c891", "type": "user", "name": "Mika Tanaka" },
"message": {
"id": "msg_20260704_001",
"type": "text",
"text": "Can you check whether my appointment moved to Monday?",
"direction": "inbound",
"sent_at": "2026-07-04T02:18:29Z"
},
"event": { "kind": "message_received" }
}
}你的 webhook 端点可以订阅 message.received，也可以用 ["*"] 订阅完整标准事件目录。如果启用签名，每次投递都会带上 X-Device-Timestamp 和 X-Device-Signature。签名是使用该端点的 signing_secret，对时间戳、一个点号和原始请求体做 HMAC-SHA256 后得到的十六进制值。
这样路由服务的规则就很清楚：先验证签名，再按事件 ID 去重，保存需要的 payload，然后路由消息。rich menu insight 调用不应该进入这个路径。
LINE 官方洞察应该放在哪里
新的 insight 端点有价值，但它回答的是另一个问题。
你可以用它统计 rich menu 里的“客服”区域是否比“价格”区域点击更多，也可以比较工作日和周末的互动差异，还可以判断季节性菜单是否值得继续上线。调度频率应该保持低速：业务报表每天一次，活动期间最多每小时一次。
不要用它推断用户是否正在等待客服。rich menu 点击不是消息。按天汇总的洞察报表不是队列。带有 10 rps 限流的配置端点也不是路由原语。
最简单的拆分方式是：
| 关注点 | 最合适的数据源 | 时机 |
|---|---|---|
| rich menu 展示和点击报表 | LINE rich menu insight 端点 | 每小时或每天 |
| 当前 rich menu 配置 | LINE rich menu list 端点 | 缓存，远离热路径 |
| 实时客户消息 | UnifyPort message.received webhook | 即时事件 |
| 跨平台路由 | UnifyPort 标准 webhook 信封 | 每个平台共用同一 handler |
这种拆分也让团队更稳定。分析任务失败时，客服队列仍能收到消息。rich menu 报表延迟时，CRM 仍会记录每一条入站会话。以后加 WhatsApp 或 Zalo，路由循环不用重写，只有分析循环仍然是 LINE 专属。
一个小团队可落地的架构
小团队不需要复杂架构。
先注册一个 UnifyPort webhook 端点，设置 signing_secret，订阅 message.received。在 handler 中验证 X-Device-Signature，保存原始事件，并按 provider、account_id、data.sender.id 和 data.message.type 路由。
再单独跑一个定时任务处理 LINE 官方 rich menu 报表。这个任务调用 insight 端点，把指标写进数仓或表格，绝不阻塞入站路由。它也可以刷新 rich menu list 缓存，但这个缓存对客服 handler 应该是只读信息。
当客服团队需要回复时，出站路径仍然是明确的：通过 POST /v1/messages 发送目标账号和消息内容。入站事件则继续作为“谁在什么时候说了什么”的事实来源。
最终模型很清晰：
- LINE 官方 API 负责 LINE 专属分析。
- UnifyPort 负责多平台标准化入站投递。
- 客服后端不在消息路径里轮询官方配置端点。
- 增加另一个聊天应用时，变化的是数据，不是架构。
真正的提醒
LINE 7 月 1 日的 insight 更新，对关心 rich menu 表现的团队是好消息。5 月 26 日的限流变化则划出了一条边界：不要把 rich menu 配置当成实时消息基础设施。
如果你的 LINE 工作主要是营销分析，就使用新的官方 insight 端点。如果你的工作是客户运营，就让入站消息走事件驱动。如果团队已经同时接收 LINE、WhatsApp、Zalo、Telegram、TikTok 或 X 上的客户消息，就使用同一种 webhook 结构，让所有平台进入同一套路由管道。
分析可以轮询，客户消息应该直接到达。