Cookie 越攒越大：目录站那些请求头是怎么把每个请求都拖慢的

localStorage 和 IndexedDB 存在浏览器里，你不主动发，它们就不会动。Cookie 不一样——它是唯一一个「只要设了，之后每个同源请求都会自动带上」的存储机制。这个特性当年是为了做会话，现在被一堆东西蹭着用。

一个统计脚本写三个，A/B 实验写两个，主题偏好写两个，再加一个会话 ID 和一个 CSRF token，两年下来一个请求头上挂两三千字节很常见。

图片来源：网络，版权归原作者所有，侵权请联系删除

限制到底是多少

项	规范要求	浏览器实际
单个 Cookie 大小	至少支持 4096 字节	约 4096 字节
每个域名 Cookie 数	至少 50 个	50 到 180 个不等
总大小	规范未硬性规定	大致 80 到 180 KB

最关键的一句：超过限制时浏览器是静默丢弃的，没有报错，没有控制台警告。所以 Cookie 莫名其妙失效这类问题，排查起来特别费劲——它不像超时的报错那样有迹可循。

它是怎么拖慢 TTFB 的

机制有两层。第一层是包大小：以太网的 MTU 通常是 1500 字节，请求头一旦超过它，一个 HTTP 请求就要拆成多个 TCP 包，多一次往返，重传风险也上升。Cookie 加进 1KB 以上，很容易撞上这条线。

第二层是压缩的局限。HTTP/2 用 HPACK 压缩头部，重复的 Cookie 串确实能被压掉大部分。但有两个前提不成立的情况：一是新连接或者长时间断连后的第一次请求，动态表是空的，整个 Cookie 串得原样发一遍，而这次请求通常就是 HTML 本身；二是有些服务端出于安全考虑（Cookie 是 CRIME 类攻击的重点目标）故意不压缩它。

所以业内的经验值是：把所有 Cookie 加起来的总大小控制在 900 字节以内比较稳，给 User-Agent、Accept 这些其他头部留出余量。这不是规范，是从实测数据里总结出来的参考线。

无 Cookie 域这条建议现在还成不成立

HTTP/1.1 时代的标准建议是：静态资源放一个单独的域名，那个域名不设任何 Cookie，这样图片和脚本的请求就不带 Cookie 了。这个思路本身没错，但放到 HTTP/2 环境下要重新算账：

多一个域名就多一次 DNS 解析和一次连接建立。HTTP/2 的多路复用让「多个请求走一条连接」成了常态，为一个不设 Cookie 的域名单独建连接，省下的那点请求头未必抵得上这次握手的成本。

结论是：如果你的静态资源本来就放在 CDN 域上，那就顺便解决了，不用额外做；如果还在主域下，与其为了这条建议专门加一个域名，不如先把 Cookie 本身减下来——后者收益更确定。

目录站上常见的膨胀来源

• 第三方统计和广告脚本。它们写的 Cookie 你控制不了，但可以选择要不要挂这个脚本，以及能不能延后加载。
• A/B 实验标记。实验结束后忘了摘，标记会一直留在用户浏览器里。给实验标记设一个明确的过期时间是必须的。
• 主题、深色模式这类偏好。它们不需要服务端知道，放 localStorage 更合适，服务端不参与就不会进请求头。
• Domain 设得太宽。写成 Domain=.example.com，子域下的静态资源请求也会带上它。不带 Domain 时 Cookie 只匹配精确主机名，这个默认值反而是对的。
• 把用户信息塞进 JWT 再放进 Cookie。头像地址、角色数组、功能开关——这些每请求都要重复发送的东西，改成服务端会话，Cookie 里只留一个不透明的 ID。

排查顺序

第一步，DevTools 的 Network 面板，点任意一个请求看 Headers 标签页里的请求头大小。这个数是全量，包含 Cookie，一眼就能看出问题有没有。

第二步，Application 面板的 Cookies，按大小和数量排序，找出占地方的那几个，看看是谁写的、有没有必要。

第三步，量一下服务端视角。反向代理返回 431（Request Header Fields Too Large）时，问题往往不在浏览器限制，而在 Nginx 或 CDN 那一段的头部缓冲区大小。用 curl 直接量一下请求头的字节数，比猜快得多：

curl -s -o /dev/null -w '%{size_request}\n' -H 'Cookie: ...' https://example.com/

减 Cookie 这件事没什么技术含量，就是清点加克制。但它有个特点：改一处，全站所有请求都受益，而且不用改任何业务逻辑。这种投入产出比在性能优化里算是排在前面的。