商品详情页的埋点把整份规格和推荐位列表都拼进查询串 上线后访问日志里出现一批 414 报表里这段行为整块缺失 前台一点提示都没有。乍看像缓存或者权限的锅，追下去往往不是。
curl -s -o /dev/null -w '%{http_code}' https://e.com/c?d=1
追下去是这么回事：GET 查询串长度受服务端和中间层限制 常见上限是 8KB 埋点字段越加越多很容易越线 超了直接 414 前端拿不到任何反馈 改完还得回头看中间层。
碰到「埋点 URL 过长」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
具体做法是，提交方式从 GET 换成 POST 之后 长度限制一下就宽松很多；URL 里只留事件名和 id 明细挪进请求体 顺带更好压缩；上线前统计一次 URL 长度分布 超过 2KB 的先拆掉重新拼。
验收就看一点，访问日志里不再出现 414 报表里的事件数和前台点击次数能对上。