cookie 应严格控量、减载、分流，仅存必要标识和不可逆会话键，避免业务数据和敏感信息；需精确计算字节数并预留余量，超限时截断或分片；静态资源应隔离域名杜绝cookie传输。
Cookie 体积过大直接影响 HTTP 请求头大小，每次同域请求都会自动携带，造成冗余传输、延迟上升，尤其在移动端或弱网环境下更明显。避免影响网络传输性能的关键，不是等它变大再“处理”，而是从设计和写入阶段就主动控量、减载、分流。
只存必要标识，别塞业务数据
Cookie 的本质是维持状态，不是本地数据库。用户偏好、购物车详情、页面配置等完整结构化数据，绝不能直接序列化后塞进 Cookie。
- 用短 ID 替代全量内容：比如存
cart_ids=1001,1002（约 20 字节），而不是cart_items=[{"id":1001,"name":"手机","price":2999},...]（极易超 4KB） - 敏感信息一律不存：密码、手机号、token 明文、完整权限列表等，必须由后端管理，Cookie 中仅保留不可逆的 session key 或 token ID
- 登录态与业务态分离：登录凭证（如
auth_token=abc123）可存 Cookie；用户主题、布局、通知开关等应存在 localStorage，需要时再同步到服务端
严格计算字节，预留安全余量
4KB 是硬性上限（4096 字节），且包含 name + value + 属性（如 ;path=/;expires=...）。中文、emoji、特殊符号 UTF-8 编码占多字节，.length 会严重误判。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 真实字节数用
new TextEncoder().encode(str).length计算，不是str.length - 写入前预估总长：name 字节数 +
encodeURIComponent(value)后字节数 + 属性开销（通常 30–50 字节） - 务必预留至少 100 字节余量，防止因时区、日期格式、浏览器实现差异导致静默截断
拆分、压缩或换存储方案
当业务确实需传递中等体量状态（如用户界面快照），优先考虑替代路径，而非硬塞 Cookie。
- 超限时主动截断并标记：JSON 序列化后测长，超限则 truncate 并加
"…truncated"，后端识别后补全 - 分片存多个 Cookie：如
pref_v1=...、pref_v2=...，但同一域名下总数建议 ≤ 40 个，避免请求头膨胀 - 前端压缩 + 后端解压：用
pako压缩 value，Base64 编码后写入；服务端用Deflater解压。注意权衡 CPU 开销与带宽节省 - 更推荐方案：改用
localStorage存状态，关键操作（如登录、支付）时通过轻量 API 同步到服务端，Cookie 仅用于身份凭证
隔离静态资源，杜绝无意义传输
图片、CSS、JS 等静态资源请求完全不需要 Cookie。若它们也携带了 Cookie，纯属带宽浪费。
- 为静态资源单独配置无 Cookie 域名，例如
static.example.com，且确保主站 Cookie 的domain不设为.example.com - 若用子域名，Cookie 必须明确指定
domain=www.example.com，而非顶级域，否则static.example.com请求也会附带 - 后端中间件（如 Express 的
cookie-parser）应路由级启用，仅对/api等动态接口解析，静态资源路径跳过
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
