背景:生产此前**完全统计不了 PV/UV** —— 前端无任何分析埋点(gtag/umami/plausible 全无),服务端无 request log,生产 ECS 上更没有 nginx(pac.friday.tech 走独立网关 lb1.friday.tech,访问日志不在我们这台机器上)。Sentry 只有 10% tracing 采样, 做 UV 会系统性偏低。 范围限定在 plan 详情页(切合 plan_event_logs 表名):plan_id / patient_id 本就是 该表的必填列,浏览事件天然填得上,不必为它放宽约束或另立新表。 三种入口按用户口径**全收**:直接进/刷新 · 患者列表 rail 切换 · /plans 落地自动跳转。 (自动跳转确实是系统行为,但业务侧确认要收 —— 它也代表这条 plan 被展示过。) ⭐ 唯一的雷:byHuman 不是"是不是人做的",是**口径开关** HUMAN_TOUCH_EVENTS 靠 filter(byHuman) 派生。view 按字面语义该写 true,但那会让 「客服处理过哪些患者」静默膨胀成"看一眼也算处理"——刚交付的 65 人统计与整张 客服明细 Excel 全部失真,**而且不会有任何编译错误或类型报错**。 故 view 写 byHuman:false,并把该字段注释从"是否人工动作"改写成明确的口径定义; spec 里用**精确相等**(非 arrayContaining)锁死 HUMAN_TOUCH_EVENTS 的四个成员, 以后新增事件必须显式决策要不要计入,改错即红。 改动: - enums: PlanEventType.VIEW + PLAN_EVENT_META 项(group 联合类型扩 'view') - controller: POST /pac/v1/plans/:id/view。**刻意不加认领闸**(区别于 recall-feedback)—— 浏览发生在认领之前,池子里任何一条都能点开;加闸则埋点只剩已认领的,PV/UV 直接废掉。 plan 不存在静默返回 not_found:埋点是旁路,不能因它失败而影响页面。 - 前端: 埋点挂在 use-plan-aggregate 现成的去重守卫里 —— 该守卫原为防 StrictMode 双调, 其语义恰好等于"每进入一次详情页";refresh() 直接调 load() 走不到这里,故手动刷新不重复计。 失败 .catch(()=>{}) 吞掉。 验证(本地起真实前后端 + 浏览器实操): /plans 自动跳转 → 记 1 条 ✓ 手动点刷新 → 仍 1 条(不重复计)✓ 重新进入页面 → 累计 2 条 ✓ 未认领查看 → 能记 ✓ plan 不存在 → not_found 不报错 ✓ 无 token → 401 ✓ ⭐ 只有 view 事件的患者,在「处理过」口径下计 0(全事件口径会误计 2)✓ 640 tests passed,service/web typecheck 通过。 无 DB 迁移(event 是既有 text 列,加的是取值不是列)。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
