应使用JSON提交日志：表单设enctype="application/json"并用JS拦截submit，通过FormData提取后结构化为JSON，服务端声明Content-Type: application/json；避免GET、深层嵌套及编码乱码。
表单提交时如何避免日志字段被截断或乱码
HTML 表单默认用 application/x-www-form-urlencoded 编码，对中文、特殊符号、长文本支持差，日志系统收到的 payload 经常出现字段缺失或 %E6%9F%90%E4%B8%AA%E5%AD%97%E7%AC%A6 类乱码。这不是后端解析问题，而是前端没主动控制编码边界。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有日志采集表单显式设置
enctype="application/json"（需配合 JS 拦截 submit） - 用
JSON.stringify()构造 payload，而非依赖浏览器自动序列化 - 对字段值做预处理：用
encodeURIComponent()处理单个字段再拼接，比整个 body 用encodeURI()更可控 - 服务端必须声明
Content-Type: application/json，否则 Nginx 或网关可能按 form-data 解析并丢弃非 ASCII 字段
如何让 form.submit() 触发 JSON 提交而不刷新页面
原生 <form> 不支持直接发 JSON，submit 默认触发 full-page navigation。强行用 fetch 替代会丢失表单验证、disabled 状态同步、回车提交等原生行为。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
form.addEventListener('submit', e => { e.preventDefault(); ... })，但保留checkValidity()调用 - 用
new FormData(form)提取字段，再手动映射为结构化对象：{ event_type: fd.get('type'), timestamp: Date.now(), payload: JSON.parse(fd.get('raw') || '{}') } - 避免直接
JSON.stringify(fd)——FormData不可直接序列化，会得空对象 - 提交前加
fetch(..., { keepalive: true })，防止用户切页导致日志丢失
日志字段嵌套层级过深导致 Elasticsearch mapping explosion
前端把整个 event.detail 或 window.performance 对象塞进一个 payload 字段，后端未做扁平化就直写 ES，结果触发 limit of total fields [1000] in index 错误。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 约定字段白名单：只允许
['user_id', 'action', 'duration_ms', 'error_code']等 8–12 个核心字段上行 - 嵌套数据（如堆栈、性能指标）统一存为
extra字段，并设为"type": "keyword"或"enabled": false防止自动 mapping - 前端用
JSON.stringify(obj, ['user_id','action','duration_ms'])第二参数做 key 过滤，比后端清洗更早止损 - 在表单
data-log-schema="v2"属性中标明版本，便于后端路由分流处理
为什么用 POST 而不是 GET 提交日志，以及 URL 长度陷阱
GET 请求看似简单，但实际埋了两个雷：一是浏览器和 CDN 对 URL 长度限制不一（Chrome 限制约 2MB，Cloudflare 默认 4KB），二是所有日志参数暴露在 access log 和浏览器历史中，违反 GDPR 审计要求。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 强制使用
POST，且action属性指向专用日志 endpoint，如/api/v1/log - 避免在 URL query 中传任何业务字段，哪怕只是
?source=form_login—— 改用body的source字段 - 若必须兼容旧网关（只认 GET），用
fetch+method: 'GET'+body（部分网关支持）不如直接升级网关配置 - 测试时用
curl -X POST -H "Content-Type: application/json" --data-binary @payload.json https://log.example.com验证服务端接收逻辑
字段命名一致性、时间戳精度（毫秒级）、错误字段是否包含 stack trace 原始行号——这些细节不会报错，但会让后续排查慢 3 倍以上。
