表单提交应统一使用 enctype="multipart/form-data" 并手动流式解析，字段名强制小写加下划线，fetch 提交时勿设 Content-Type 头，提交后禁用按钮并用 crypto.randomUUID() 生成 event_id，失败日志存 localStorage 限重试 2 次，Kafka 入仓前需字段截断、校验与 UTF-8 规范化。
表单提交时 enctype 选错直接导致日志字段丢失
默认的 application/x-www-form-urlencoded 会把空格转成 +、特殊字符 URL 编码，后端解析时若没严格还原，user_agent 或 referral_url 这类字段就容易截断或乱码。日志系统依赖结构化字段做实时聚合，一个字段解析失败可能让整条日志进错 topic。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 统一改用
enctype="multipart/form-data"，哪怕没有文件上传——它天然支持原生二进制边界分隔，字段值不经过 URL 编码，保留换行、引号、控制字符 - 服务端接收时别依赖框架默认的 form 解析（如 Express 的
body-parser不处理multipart），改用busboy或formidable手动流式解析，避免内存暴涨 - 所有字段名强制小写 + 下划线，比如
event_type而非eventType，规避大小写混用在 Kafka Schema Registry 中触发重复注册
fetch() 提交表单时忽略 Content-Type 头引发的序列化陷阱
手动构造 FormData 并用 fetch() 提交时，如果显式设置 Content-Type，浏览器会禁用自动添加 boundary 的逻辑，后端收不到分隔符，直接解析失败。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 绝对不要给
fetch()的headers里加Content-Type: multipart/form-data—— 让浏览器自动生成带随机 boundary 的 header - 需要透传元信息（如 trace_id）时，走 URL query 或额外 header，比如
headers: { 'X-Trace-ID': 'abc123' }，别塞进 form 字段里增加解析负担 - 字段值含 JSON 字符串？先
JSON.stringify()再 append，后端收到的是字符串字面量，不是自动解析后的对象，避免类型误判
高并发下 submit 事件阻塞导致日志漏采
用户快速连点提交按钮，或页面未防抖就绑定 form.addEventListener('submit', ...)，会触发多次重复请求。日志系统按 event_id 去重，但前端生成逻辑若依赖时间戳+随机数，短时间高并发下碰撞率飙升。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 表单提交后立即禁用提交按钮：
form.querySelector('[type=submit]').disabled = true，同时设data-submitted="true"防二次触发 -
event_id改用crypto.randomUUID()（现代浏览器）或self.crypto.subtle.digest()哈希当前时间+页面 URL+滚动位置，比单纯Date.now()更唯一 - 网络失败时别静默丢弃——把 payload 存进
localStorage，页面重载后检查并重发，但要限制最多重试 2 次，避免日志积压
Kafka Producer 接收表单数据前必须做的三件事
后端拿到 multipart 请求后，不能直接把原始 Buffer 往 Kafka 里 send。字段缺失、超长、编码异常都会污染整个 partition 的消费进度。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 每个字段做长度硬限制：如
page_url> 2048 字节则截断并打标"url_truncated": true，不拒绝整条日志 - 对
user_id、session_id等关键字段做正则校验（如只允许字母数字下划线），非法值统一置为"unknown"，保持 schema 兼容 - 日志体必须是 UTF-8 编码的纯 JSON 字符串，禁止嵌套 HTML 片段或 JS 对象字面量；遇到非 UTF-8 字节序列（如 GBK 表单），用
iconv-lite转换后加"encoding_hint": "gbk"字段留痕
