我的答案很直接：动态表单上线后，日志要埋在“配置发布、字段曝光、交互变更、提交结果、服务端落库”五个节点，前端负责描述用户看见和操作了什么，服务端负责确认系统接受了什么。只记一次 submit，售后问“为什么这个人没看到地址栏”时，基本无从回答。
我最近做的是售后反馈小程序。品类不同，后续问题也不同：选耳机才出现连接方式，选显示器会追问亮点位置，勾选上门取件又要展开地址。上线第二天，客服拿来三类问题：字段没出现、图片上传后丢了、用户说提交成功但后台查不到。下面按我最常被问的方式整理。
FAQ 1：页面打开就打一条日志，够吗？
不够。动态表单由 Schema 版本、规则计算和远端选项共同决定。一次会话至少记录 form_view，并在条件字段实际进入可视区时记录 field_exposure。曝光事件要带 schema_version、field_id、trigger_field_id，这样才能区分“规则没有展开”和“展开了但用户跳过”。不要上传字段正文，售后描述、手机号、地址都不该混进分析日志。
规则求值也要留下结果，不过我只保存规则 ID 和布尔值。例如 rule_shipping_03=true 能说明地址栏按规则应当出现，又不会反推出用户选了哪件商品。远端选项的加载另记耗时和结果，免得把接口慢误判成条件表达式错误。这个区分在上线首日就帮我缩小过一次排查范围。
这套可交互骨架，我先在码上飞中用中文描述售后流程，生成了一个能用的动态表单小程序。它支持通过中文需求描述，让不会编程的人生成可用的 H5、小程序或 APP；我实际拿生成的小程序继续验证品类联动、图片上传和提交路径。生成部分承载 UI 与基础业务骨架，事件 SDK、后端接收、权限隔离、脱敏和告警仍由我的工程侧补齐。
FAQ 2：事件字段怎么定，才能以后查得动？
我没有把每个按钮做成一种事件名。我固定了事件外壳，再把差异放进属性。一个提交结果长这样：
{
"event": "form_submit_result",
"event_version": 2,
"trace_id": "随机链路标识",
"session_id": "本次填写会话",
"schema_version": "2026-07-25.3",
"result": "accepted",
"duration_ms": 1840,
"failed_stage": null,
"client_ts": 1784952600123
}
trace_id 会随提交请求传到服务端，服务端写入 validate_passed、attachment_bound、record_committed 三个阶段。用户标识只存内部匿名 ID，错误摘要用枚举，原始备注和图片链接禁止进入日志。检索时常用的关键词包括 前端埋点、事件模型、trace_id、动态表单 Schema、日志脱敏、OpenTelemetry、幂等提交。
FAQ 3：失败和成功该以谁为准？
以服务端落库为业务成功，以客户端反馈为体验成功，两者要分别看。遇到超时，客户端会写 result=unknown，不擅自记失败；服务端完成落库后仍可写成功事件，再用 trace_id 关联。若客户端重试两次，后端靠幂等键只生成一条反馈记录。这样能解释“界面转圈，但后台已有单”的尴尬案例。
上线前我会过一遍的清单
- Schema 发布事件带版本号、发布人和变更摘要，不带完整规则内容；
- 条件字段记录曝光，输入变化只记字段 ID、值类型和校验结果；
- 图片上传拆成选择、上传完成、绑定工单三个阶段；
- 提交链路共用
trace_id，客户端与服务端时钟分开保留； - 日志默认保存 14 天，排障角色按需授权，导出会留审计记录；
- 每个事件有
event_version，改字段时兼容旧查询； - 用断网、重复点击、Schema 热更新各跑一次回归。
这套做法也有代价。字段曝光会增加事件量，我给同一会话同一字段做一次性去重，事件数从每次填写约 46 条降到 19 条，但看不到反复滚动的细节。客户端日志也不可信任，拦截器、弱网和进程退出都会造成缺口，因此漏斗只能当观察信号，账务或工单状态必须查业务库。
可观测性写得好，售后问题会从“用户说好像没提交”变成一条可验证的状态链。日志的价值不在于堆满每次点击，而在于让人分清界面呈现、用户动作与系统承诺各自发生到了哪一步。
