题目与场景
服务器拒绝解析超过配置上限的请求目标。原因可能是客户端序列化、重定向循环、Cookie 或代理边界，因此只提高一个服务器限制未必有效。
面试官考察什么
- 定位哪一跳的哪一个请求组件超限。
- 把数据从 URI 移到请求体时保持 HTTP 方法语义。
- 设计有界、可观测的查询契约，而不是接受任意长 URL。
作答前的澄清问题
- 超长发生在路径、查询、重定向 Location，还是编码后的状态块？
- 哪一跳返回 414：浏览器、CDN、负载均衡、网关还是源站？
- 操作是安全且可缓存的读取，还是会修改状态？
- 是否需要可分享 URL、书签，或需要保护筛选隐私？
30 秒回答框架
我会记录请求目标长度和产生 414 的跳点，再检查重定向、Cookie、编码与筛选序列化。只读搜索若筛选集合过大，我会增加有界 POST 搜索接口或短期服务端查询令牌，明确授权、缓存与审计规则。不会只提高单个代理上限而跳过全链路测试，也不会静默截断条件。
分步深挖
1. 测量真实请求目标
记录安全的长度指标、路由模板、重定向次数和关联 ID，不记录敏感查询值。比较浏览器、CDN、网关和源站限制。Base64 状态块、重复参数或重定向循环可能在应用代码执行前就让 URI 增长。
2. 保持方法与缓存语义
GET 安全且自然可缓存，但 URL 不是无限数据传输通道。把大筛选集合移到 POST 会改变缓存和书签行为，应定义专用接口、响应缓存策略和幂等预期。不要只为隐藏变更语义而把操作改成 POST。
3. 限制并规范化筛选
限制条件数量、值长度、嵌套深度和总编码字节数，一致拒绝格式错误或重复参数。规范化等价筛选，避免缓存和签名把参数顺序差异当成不同请求。
4. 需要分享时使用查询令牌
服务端保存带短 TTL 的规范化筛选对象，并绑定租户、用户授权及一次性或限定范围的读取。返回可放入 URL 的短令牌。令牌或查询字符串不得放秘密和原始个人数据，并执行过期与撤销。
5. 把 414 当作运营信号
按路由、客户端版本和代理跳点监控发生率，跟踪重定向链与序列化变更。安全回退可以提示用户减少筛选，或提交到请求体接口；不能静默丢弃条件。
高质量示范回答
“我会先测量目标长度并定位哪一跳产生 414，再检查重定向、Cookie、编码和重复筛选。只读搜索超过 URL 限制时，增加有界 POST 搜索接口或带授权的短期查询令牌，明确缓存和审计语义。限制条件数与编码字节，绝不静默截断，并按路由和客户端版本监控 414。只有测量、协调配置并完成滥用测试后才考虑提高某一跳上限。”
常见误区
- 只提高源站上限 → CDN 或网关仍可能拒绝 → 测量并协调每一跳。
- 把数据移到 POST 却不说明缓存性 → 客户端失去预期语义 → 定义缓存、分享和幂等行为。
- 截断超长筛选 → 结果不再代表用户查询 → 明确拒绝或使用有界替代接口。
- 在查询令牌中放秘密 → URL 会进入日志和 Referer → 使用有范围、可过期和可授权的不透明令牌。
追问与回答
414 只由查询字符串造成吗？
不是。请求目标包含路径和查询，重定向也可能生成过长目标。Cookie 影响的是请求头限制而非 URI，因此诊断必须识别具体超限组件。
所有大 GET 都应改成 POST 吗？
不应。普通安全且可缓存读取继续使用 GET；当请求表示无法适应实际 URI 限制时，再使用定义清晰的 POST 搜索契约，并说明缓存和分享行为变化。
为什么不把所有限制都大幅提高？
超长目标会消耗解析、日志、缓存和安全资源，并造成跳点限制不一致。只有在有测量需求、协调配置并完成滥用测试后才提高限制。