项目里踩过的四个坑
每一个都不是查一次文档就能解决的问题 —— 需要建立诊断脚本、收集真实数据、 在多种方案中权衡后才收敛到当前实现。其中"漏邮件"是最具代表性的一次深度根因分析。
本地 6000 封的搜索性能
正文全文匹配走 JavaScript String.includes？先做基准 —— 6000 封数据 200ms 内返回，够用；再补 JSON.stringify 全字段搜避免漏字段。
AI 回复怎么打分才客观
放弃"关键词绝对分数"（受写作风格影响太大），改用"当日 P25/P50/P75 相对分位数"—— 每封回复的分数都是相对同批次的位置，永远可比。
规则库怎么表达才不误伤
最初用"关键词 AND 组合"，['两个','套餐'] 大量误伤正常回复；迭代到"连续短语 OR"，只有完整命中 '可以同时持有多个套餐' 才算违禁。20+ 合规 + 200+ FAQ 全从真实邮件回溯打磨。
"漏邮件" Bug 的三轮根因追查 深度案例
用户反馈"某个邮箱少了 5 封邮件"—— 时间判停 → 猜接口乱序 → 换 ID Set 判重。下方是完整复盘过程。
"漏邮件" —— 从时间判停到 ID Set 判重
症状：用户反馈某个邮箱只显示 2 封，实际有 7 封
本地 IndexedDB 里就是只有 2 封，不是搜索问题。数据同步在"某个环节"漏了 5 封 —— 这 5 封时间集中在 07-04 14:33 到 15:47 之间，74 分钟窗口。
假设：Coze email/list 接口不是严格倒序
用诊断脚本抓 连续 200 页原始返回 分析时间序列 —— 发现第 30 页突然冒出一封 07-04 15:47 的邮件，比第 29 页的 07-03 邮件还新。确认接口存在轻微乱序。
定位：增量同步的"停车"逻辑触发太早
原逻辑："连续 60 封 received_time ≤ anchor 才停车"。极端乱序时，30 页老邮件之后才冒出新邮件，60 封窗口不够 —— 已经停车了。
方案 A（拒绝）：调大窗口
把 60 改成 500 能兜住这次，但下次接口乱得更狠还会漏。"猜"的方案不解决问题，只是把风险后移。
方案 B（根治）：换 email_id Set 判重
停车条件改成"连续 3 页所有邮件 ID 都在本地 Set 里"。乱序邮件必然带新 ID —— 一旦某页有新 ID 就重置计数继续翻。对任意程度的接口乱序完全免疫。