访客端能收到客服发送的常见问题但只显示未读过的吗？

美洽默认会把“常见问题”当作对话窗口或侧边卡片持续显示给访客，不会自动只呈现“未读”条目。要做到只显示未读，需要你自己记录访客是否已查看或点击（比如用 localStorage、登录用户属性或服务端标记），再通过美洽 SDK/API 拉取或自定义渲染筛选结果。

一句话先把事情说清楚（费曼法第一步）

简单来说，美洽的内置展示是“建议性”而不是“已读管理器”。也就是说，平台会把配置好的常见问题展现在访客端，但不会帮你记住哪些问题已经被某个访客看过、点过或忽略。如果你需要“只显示未读”，就得在展示层或后端自己做一点工作，把“已读”状态记录下来，再过滤掉已读项。

为什么会是这样？先理解机制再做选择

把这事拆开来看，涉及三个角色：

• 美洽平台：负责存储和管理常见问题（FAQ）、提供 SDK/API，以及在聊天窗里把这些问题以卡片或建议列表形式展示。
• 访客端：看到内容并可以点击、阅读或忽略。访客可能匿名、也可能登录；他们可能在不同设备间切换。
• 你的业务逻辑：决定什么算“已读”、如何存储这个状态，以及是否跨设备、跨会话同步。

美洽默认侧重统一的 FAQ 管理和即时展示，而不是个性化的“已读过滤”。这既能保证简单易用，也避免平台替每个业务实现复杂的状态同步逻辑（例如访客匿名与跨设备问题）。

常见误解

• 误解一：“我在美洽后台设置了常见问题，访客就能自动只看到未读的那部分” —— 不成立。
• 误解二：“消息的已读/未读等同于 FAQ 的已读状态” —— 两者不同，消息读/未读是会话层面的；FAQ 展示更多是 UI 建议层面。

可行的实现路径（按从简单到稳健排序）

下面列出几种可选方案，你可以根据产品规模、是否需要跨设备同步、以及实现成本来选择。

方案 A：前端 localStorage（最简单，适合匿名访客或短会话）

思路是：当访客点击某条常见问题或页面渲染时，把该问题的 ID 写入 localStorage。每次渲染常见问题前，先从 localStorage 读取已读 ID 列表并过滤出未读项显示。

• 优点：实现简单、延迟低、不依赖后端。
• 缺点：仅限同一浏览器同一设备，同一访客换设备或清除缓存后丢失。
• 适用场景：匿名访客、无需跨设备同步的低成本方案。

方案 B：前端结合用户登录（中等复杂度）

如果你的用户需要登录，那么可以把已读信息写到用户的 profile（或你自己的后端），每次访客打开页面时用用户 ID 请求已读列表并在前端过滤 FAQ。优点是跨设备同步、用户体验更连贯；缺点是需后端支持和鉴权。

方案 C：服务端持久化 + 美洽 API（最稳健，适合复杂业务）

把已读状态保存在你自己的数据库，并把这个状态与美洽的会话或用户 ID 关联。渲染 FAQs 时由服务端先把已读过滤好，再返回给前端。可以利用美洽开放 API 获取 FAQ 列表或同步用户会话信息来做更细致的逻辑处理。

• 优点：可以做完整统计、跨设备同步、和复杂的个性化规则（比如按用户行为推荐）。
• 缺点：开发成本较高，需要维护后端与美洽对接。

方案 D：自定义小窗/插件替代默认展示（可完全控制）

如果默认美洽小窗无法满足需求，可以自行实现一个展示层（比如使用美洽提供的 API 只是做消息发送/接收，而自己来渲染 FAQ 列表）。这样你可以完全控制哪些条目该显示、如何标注已读、以及交互逻辑。

实现细节：一步步做（以方案 B/C 为主）

下面把一个比较完整的实现流程列出来，给你可以照着复制的步骤。

1）定义“已读”的语义

• 是“只要渲染到屏幕就算已读”还是“用户点击过才算已读”？
• 是否需要标注“已读时间”？
• 是否要统计“阅读次数/偏好”来优化排序？

2）确定数据结构

后端存储示例（简化）：

3）事件采集（前端触发）

当访客点击某条 FAQ 或展开详情时，触发一个事件：

• 如果访客已登录：调用你后端的 API 记录为已读；
• 如果访客匿名：写 localStorage，同步到服务端的时机可以是后续登录或者会话结束上传；
• 为了分析可以把点击数据也回传给美洽作为自定义事件（如果你需要在美洽后台看热度）。

4）渲染逻辑（前端）

页面加载时：

• 向后端请求 FAQ 列表（或直接用美洽 API 获取）；
• 拿到 user_id 或本地已读数组后，过滤掉已读项；
• 把过滤后的结果渲染成卡片/列表；
• 用户点击后发事件并更新本地/后端已读状态，避免重复展示。

5）跨设备与离线处理

• 登录用户：优先以服务端为准；前端可以做乐观更新（点击即隐藏），失败时再回滚。
• 匿名用户：用 localStorage 或 cookie 存储，若用户后续登陆，则合并到服务端。

对比表：不同方案优缺点一览

一些实际开发时会踩到的坑（给你省时间）

• 匿名用户跨设备问题：不要把 localStorage 当作长期解决方案，用户换设备后会丢失已读记录。
• 竞态问题：用户快速点击多条 FAQ，记得前端做去抖/防重发，后端端点要幂等。
• 隐私与合规：已读行为属于用户行为数据，存储和分析时要符合隐私策略和地区法规（比如告知用户或提供选项）。
• 离线/弱网问题：为离线场景做缓存队列，等网络恢复再上报。
• 与美洽现有组件冲突：如果同时使用美洽默认 FAQ 卡片和自定义渲染，避免重复显示同一内容。

小样例：伪代码说明（前端逻辑）

下面是简化的思路，不是完整代码，但能说明核心流程：

• 加载页面 -> fetch(‘/api/faqs’) 得到 faqList
• 如果 user 已登录 -> fetch(‘/api/user/readFaqs’) 得到 readIds
• 否则 -> readIds = JSON.parse(localStorage.getItem(‘readFaqs’) || ‘[]’)
• displayList = faqList.filter(f => !readIds.includes(f.id))
• 用户点击 faq -> sendClickEvent(); readIds.push(f.id); update UI; 同步到后端或 localStorage

如果你坚持想用美洽现有功能能做多少？

实话是：美洽本身能很好地管理 FAQ 内容、支持机器人触达和人工推送，但对于“按访客已读状态只展示未读”这种个性化过滤，它并不是开箱即用的。部分企业能通过美洽提供的事件/标签接口，把访客行为发回平台，再通过自定义页面或脚本来决定展示样式；但一般需要结合你的前端或后端实现来完成最终效果。

实践建议（怎么权衡、怎么逐步推进）

• 先做最小可行版本（MVP）：用 localStorage 实现“只显示未读”的基础逻辑，观察使用情况。
• 如果用户量和业务价值都在，升级到后端持久化并支持跨设备。
• 把“已读”定义和数据保留策略写清楚，防止以后数据膨胀或隐私风险。
• 考虑把 FAQ 的热度统计和推荐算法逐步加入，让“未读”与“更相关”结合起来，给用户更聪明的体验。

嗯，想着把这些写完，其实开发上不会特别难，难的是把业务边界和用户期待定义清楚：哪些人需要跨设备同步？哪些操作算“已读”？如果你愿意从 localStorage 试水，再根据实际数据决定是否做后端和美洽更深度的对接，那就是既实用又稳妥的路线。下面如果你需要，我可以给出更具体的 API 调用示例或前端代码片段，咱们一步步把它做成产品级功能。