企业官网建设流程全解析

1. 子cookie到底是什么：名字唬人，本质只是编码约定

1.1 从cookie的家底说起：一个cookie到底能装多少东西

聊子cookie之前，得先把cookie本身的规则捋清楚。很多人天天在用cookie，但真被问到"一个cookie最大能存多少、一个域名最多能种几个"时，能答上来的人不多。浏览器这边的通行标准是RFC 6265，它规定每个域名下最少要有50个cookie的配额，每个cookie本体（含key、等号、value）最少要有4096字节的容量。注意这里有个坑，4096字节算的是整个cookie串，不是value部分，很多人把4KB全算在value头上，结果存数据存到超限，怎么被截断的都不知道。

那子cookie是什么？一句话就能说明白：子cookie并不是浏览器规范里定义的一种特殊cookie，而是开发者自己约定的一种数据编码方式，把多个名值对塞进同一个cookie的value里，形如a=1&b=2&c=3。它没有一个专属的浏览器API，也没有独立的属性字段，本质上就是在cookie这一个壳子里，用约定的分隔符放下多个"小数据项"。

这套做法和"JSON塞进localStorage"是一个思路，区别在于cookie会自动随HTTP请求头往返，localStorage不会。换句话说，子cookie的独特价值不是"多存点"，而是"在不多占cookie数量的前提下，让多个数据项一起自动发给服务端"。

1.2 子cookie的真实形态：一个key里塞了一组名值对

直接看一段实际存在的cookie长什么样。假设一个站点要在客户端记录用户偏好、会话标识和一次A/B实验的分组，按常规思路可能会种三个cookie：

Set-Cookie: user_lang=zh-CN; Path=/; Max-Age=2592000 Set-Cookie: session_id=abc123; Path=/; HttpOnly Set-Cookie: exp_group=B; Path=/; Max-Age=2592000

用子cookie的思路，这三个就合并成一个：

Set-Cookie: prefs=lang=zh-CN&sid=abc123&exp=B; Path=/; Max-Age=2592000

看到区别了吗？prefs是cookie名，后面那段lang=zh-CN&sid=abc123&exp=B就是子cookie串。整个cookie在浏览器开发者工具里显示为一条记录，但value里实际装了三组键值。

需要注意，这种编码方式完全是约定出来的，没有任何规范强制你用什么分隔符。有人用&，有人用|，有人用~，有人甚至用JSON序列化后整体塞进去。分隔符选什么、键怎么命名、值要不要编码，全靠团队自己定。这一灵活性带来的副作用就是，接收方必须严格遵循同样的解析规则，前后端一旦有一方理解错了，轻则读不到数据，重则把整条cookie解析崩掉。

1.3 这套做法的历史成因：被20个cookie限制逼出来的土办法

子cookie之所以在早年特别流行，和旧浏览器的存储限制有直接关系。2000年前后的RFC 2109时代，规范要求浏览器支持每域名至少20个cookie，比现在的50个少得多，而IE6、IE7这些当年的主流浏览器实际表现得更保守。当时一个稍复杂的站点，光埋点、会话、用户偏好、AB实验就能轻松消耗十几个cookie，一旦配额用完，新cookie要么被静默丢弃，要么把最老的cookie挤掉，线上问题非常诡异。

在那种环境下，把多个数据项打包进一个cookie就成了一种刚需：数量上只占一个名额，通过&或者|把数据摊薄在value里。虽然后来浏览器普遍放宽到了50个乃至更多，Cookie总大小也稳定在4KB左右，但很多老项目里的子cookie代码一代传一代，一直传到了今天。因此你现在看到的很多"子cookie封装工具"，其实是历史的遗产，谈不上先进，但在特定场景下依然有用。

2. 最容易踩的四个误区：把子cookie当"独立cookie"用就完了

2.1 误区一：给某个子cookie设过期时间，指望它单独失效

这是我见过最多、踩的人死得最惨的一个坑。先看一段典型的错误写法：

// 错误示范：试图给子项设置过期时间 document.cookie = "prefs=lang=zh-CN; max-age=0";

写下这行代码的人，脑子里想的是"我把prefs里的lang这一项删掉"，但浏览器根本不管你的子项是什么，它只认prefs这个整体cookie。上面的操作实际效果是：把整个prefs直接删掉了，session_id、exp这些子项全部跟着消失。

这里的根本原因在于：过期时间是一个cookie级别的属性。你可以给整个prefs设置max-age或expires，但你没有任何机制对prefs内部的lang单独设置生命周期。当你需要让某个子项提前失效时，唯一靠谱的方式是重写整个cookie，把不需要的子项剔除后重新生成完整的value再写回去。

网上有些教程会变着花样说"把子项的过期时间设为过去以单独删除"，这本质上是在偷换概念，落地时还是要回到整包重写。不要被字面说法骗了。

2.2 误区二：删一个子项，以为重写整个cookie就行——结果全没了

有人会说，"我知道要重写，那我直接重写整个cookie不就行了？"逻辑上没错，但操作里处处是雷。看这段代码：

// 脑子里想做的是：从 prefs 里删除 lang，保留 sid 和 exp document.cookie = "prefs=sid=abc123&exp=B; Path=/; Max-Age=2592000";

表面看上去确实把lang去掉了，只写了sid和exp。但问题出在很多人写重写代码时容易丢掉属性。重写cookie时，如果新的cookie没有带上Path，很可能和旧cookie的Path不一致，导致浏览器里同时存在两条prefs——一条Path=/，一条Path=/some/path。前者能看到，后者看不到，排查起来一头雾水。

更隐蔽的坑是：你不知道当前cookie里到底有哪些子项。比如这段prefs可能由后端Java写入、前端JS写入、另一个团队的中台系统也写入，你重写时只按自己知道的字段来拼，其他字段就被你悄悄弄丢了。所以删除单个子项之前，正确流程是：先把整个cookie读回来，解析成对象，删除目标键，再把剩下的键重新序列化后写回。整个链路缺一步，都是事故。

2.3 误区三：觉得HttpOnly、Secure这些属性是"按子项生效"的

这条误解在面试里出现频率很高，实际项目里也很致命。有人会写出类似这样的方案构思："我给session_id这个子项打上HttpOnly，防止XSS读取；给lang这个子项不打HttpOnly，让JS能改。"这个想法在概念上就错了。

HttpOnly、Secure、SameSite这些属性全部是cookie级别的，作用于整个cookie，不存在"某个子项可以单独设置HttpOnly"这回事。你只要给prefs打上HttpOnly，那整条prefs对document.cookie就不可见了，JS既读不到，也写不了。反过来，如果你为了能让JS更新某个子项而放弃HttpOnly，那么整个cookie，包括session_id，都暴露在XSS风险之下。

这事儿的本质是：子cookie只是把若干数据项"物理打包"了，并没有把它们的"安全等级"也分开。如果你需要不同等级的安全边界，就应该用不同cookie去承载，而不是塞进同一个子cookie串里。这一条想不通，后面所有的封装都容易出安全问题。

2.4 误区四：不同后端/框架对子cookie的处理方式不一样

在纯前端视角里，子cookie就是读一读、写一写，似乎很自由。但一旦有后端参与，问题就来了。后端框架里对cookie的读取通常是直接按cookie名取值的，比如Java的request.getCookies()遍历后按name匹配，拿到prefs的value后自己再split——这个split的逻辑后端写错了，前端传再标准也没用。

更麻烦的是框架本身的序列化策略。有些老版本的框架会在cookie value上做URL编码，把&编码成%26，把=编码成%3D。如果你前端用&拼接子cookie，后端拿到的value里根本没有&，全是%26，解析逻辑没做decode的话，整个子cookie就废了。另外，很多后端框架默认会给cookie加引号包裹value，子cookie串会被双引号包起来，解析时忘了去引号也会出事故。

所以，前后端关于子cookie的格式约定必须成文，至少要包含四件事：分隔符用什么、键名大小写是否敏感、value是否需要URL编码、遇到空值怎么处理。这四件事没对齐，线上数据就会歪。

3. 什么时候才值得用子cookie：算清楚效益再动手

3.1 使用价值最大的场景：降低请求头体积

把多个cookie合并成一个，最大的收益不是省cookie名额，而是压缩HTTP请求头的体积。很多人没有算过这笔账，cookie的附加成本其实很惊人。

一个普通cookie在请求头里至少包含Cookie: name=value这段，连同分号和空格，一个5字节的value实际要占15字节左右。如果你的站点种了10个像session_id=abc123这样的小cookie，请求头里的cookie段大约150字节。看起来不多？但每个请求都要带，一个页面可能有几十个请求，累积起来就是几十KB的重复流量。如果是移动端弱网环境，每个请求都要为这些重复数据等一个RTT时间，体感差别很大。

用子cookie把10个cookie合并成1个，请求头里就只剩一段，value可能稍长，但总字节数通常能压缩50%左右，因为省掉了大量键名和多余的分隔符。我做过一个实际案例，把某个页面首屏请求的cookie头从870字节压到410字节，差不多省了一半。这种优化在HTTP/1.1时代效果显著，在HTTP/2时代因为头部压缩的存在，收益会打折扣，但依旧可观。

3.2 别硬上子cookie的场景：数据本身就该用Web Storage

子cookie不是万能的，很多场景用它属于自找麻烦。

比如说，你有一份用户偏好设置，只在浏览器端使用，压根不需要发给服务端。这种情况下用localStorage，存多少都没关系，5MB配额摆在那里，读写也只是同步操作，简单直接。非要用子cookie的话，数据还要塞在4KB的cookie里挤空间，每次请求还得白白背上这份流量，纯粹是浪费。

再比如，你的数据项之间生命周期差异特别大：会话token几分钟就过期，用户偏好可以放一年。这种"生命周期天然分群"的数据硬塞进一个子cookie里，要么因为token的更新导致整个cookie频繁重写，要么让偏好数据跟着短命token一起消亡，两边都别扭。

还有跨标签页实时同步的需求。localStorage有storage事件可以监听，cookie也有自己的轮询和监听方案，但子cookie的自定义格式让同步逻辑复杂不少，收益却很低。这种场景直接用标准方案更香。

3.3 一次真实的存储规划：把cookie配额算给你看

我给你一个实际可参考的规划例子。假设一个B端系统需要在前端记录以下数据：

按常规思路，前三个用普通cookie，后三个用localStorage，这样分工最合理。但如果团队规定"所有后端需要的数据必须放cookie里，且每个域名下cookie数量不超过10个"，那前三个又该如何取舍？

三个普通cookie，每个都带Path=/; SameSite=Lax这些固定成本，单条cookie的传输开销已经是value本身的数倍。改成一条子cookie后，整个会话相关的信息打包进auth=token=xxx&lang=zh-CN&tenant=1024，请求头里就一段，后端解析一次就能拿到全部字段，既减少了cookie条数，又压缩了header体积。这才是子cookie该出现的舞台。

4. 正确用法：序列化、解析与更新的落地姿势

4.1 序列化：分隔符、编码规则和长度预算

写子cookie的第一步是定"协议"，也就是value内部的格式。没有标准可循，但我强烈建议你至少遵守三条原则：

第一，值必须编码。因为子cookie值里可能包含&、=、;、空格、中文等特殊字符，直接拼接会把解析器搞崩溃。统一用encodeURIComponent编码，解析时用decodeURIComponent还原。

第二，分隔符要避开所有可能出现在value里的字符。&和=是URL查询串里的老搭档，语义清晰、不易混淆，建议优先用它们做主分隔符和键值分隔符。不要用逗号或分号，cookie规范里分号是属性分隔符，逗号在某些框架里会被特殊处理。

第三，明确Size预算。浏览器4KB限制指的是整个cookie，也就是name=value加上所有属性。所以子cookie的value部分实际可用空间大概在3.5KB左右。写代码前先算一下最坏情况下所有子项的总长度，超了就拆成两条cookie，别把宝全押在一个鸡蛋里。

序列化的工具函数很简单：

function serializeSubcookie(obj) { return Object.entries(obj) .map(([key, value]) => `${encodeURIComponent(key)}=${encodeURIComponent(String(value))}`) .join('&'); }

4.2 解析：别信直觉，写字解析器要处理脏数据

解析子cookie最容易犯的错是"假设数据永远干净"。实际上cookie数据脏得很：可能是旧版本格式，可能被用户手动改过，可能被浏览器插件截断过，可能因为超长被静默砍掉后半截。写着"宽容的解析器"才能扛住线上真实环境。

function parseSubcookie(str) { if (!str) return {}; const result = {}; str.split('&').forEach((pair) => { if (!pair) return; const eqIndex = pair.indexOf('='); if (eqIndex === -1) { // 没有等号，按空值处理 result[decodeURIComponent(pair)] = ''; return; } const key = decodeURIComponent(pair.slice(0, eqIndex)); const value = decodeURIComponent(pair.slice(eqIndex + 1)); result[key] = value; }); return result; }

注意这里有几个细节。一是用indexOf('=')而不是split('=')，防止value里残留未编码的等号导致数组长度大于2。二是遇到没有等号的裸键，不直接丢弃，按空值解析，保证向后兼容。三是decodeURIComponent要包在try/catch里，防止用户手动改坏了cookie导致整页JS报错。

读cookie值时，规则是在document.cookie里按name=定位，而不是简单地split所有分号。因为分号也可能是value里的编码内容，虽然encodeURIComponent会把分号编码成%3B，但用户手动改的脏数据可不管这一套。

4.3 更新与删除：整包重写，缺一不可

更新子cookie的正确姿势是"读-改-写"三步走，每一步都要稳。

function updateSubcookie(name, key, value) { const raw = getCookie(name); // 自己写一个按名取值的函数 const obj = parseSubcookie(raw); obj[key] = value; setCookie(name, serializeSubcookie(obj), { path: '/', maxAge: 2592000 }); }

删除某个子项，同样遵循这个模式，区别只在最后一步是删除对象属性：

function removeSubkey(name, key) { const obj = parseSubcookie(getCookie(name)); delete obj[key]; setCookie(name, serializeSubcookie(obj), { path: '/', maxAge: 2592000 }); }

写回的时候有几个坑必须提。第一，属性要和原cookie完全一致，尤其是Path，不一致会导致读写不同步。第二，要显式带上过期时间，不让浏览器把它当成会话cookie。第三，最好在写完后立即读回来做一次断言校验，防止写入失败后代码无感知，后续逻辑读到旧值继续跑。

5. 和现代方案放一起看：子cookie的适用边界

5.1 一张表看清四类本地存储

前端本地存储方案现在远不止cookie一种，把它们放在一起比较，边界就清楚了。

cookie在"是否随请求发送"这一栏是唯一，这是它的立身之本。子cookie则在不脱离cookie的前提下，优化了它的存储效率和条数管理。而localStorage和IndexedDB虽然在容量上碾压cookie，但在"自动携带"这件事上完全替代不了。

5.2 哪些项目我还在用子cookie，哪些坚决不用

我对子cookie的使用态度，可以概括成一句话：会话相关的轻量元数据，适合用；业务数据，坚决不用。

具体来说，我目前还在用子cookie的场景有两类。一类是网关鉴权信息，多个微服务共享的token、tenant、userId、语言标识，打包在一个cookie里，后端网关解析一次就能拿到全部上下文，省去了多个cookie的重复解析，请求头也清爽。另一类是A/B实验分组，页面里可能同时跑着五六个实验，每个实验一个分组编号，如果各自独立成cookie，一下就占掉六七个名额，用子cookie打包成一个exp=exp1=A&exp2=B&exp3=C，管理起来方便得多。

坚决不用的场景是：图片验证码的校验值、表单草稿、用户偏好这种"本就不该出浏览器"的数据。这些数据塞进cookie里，不但让每次请求的header变大，还增加被攻击面，收益为零，纯属自残。我甚至见过有人把购物车完整JSON塞进cookie的，一个购物车几十KB，直接就把cookie撑爆了，页面功能就乱了。

5.3 如果决定要用，这几条铁律收好

根据我踩过的坑，给你几条实战铁律。

第一，格式文档化。用子cookie之前，先写一份简短的接口文档，包含分隔符、编码规则、字段含义和示例，贴在项目README里。这份文档能救你一命，尤其在团队换人之后。

第二，总大小留余量。不要把一个cookie的value用到3.5KB以上，留出至少500字节的余量，因为后续加字段很快。一旦触发4KB截断，数据悄悄丢一片，排查起来极其痛苦。

第三，解析函数要容错。上面给的parse函数里加上try/catch，解析失败时返回空对象，而不是让异常冒泡打断页面主流程。cookie不是可信数据源，它可能被用户、插件、代理任意改写，防御性编程是底线。

第四，服务端解析逻辑同步维护。如果cookie要被后端使用，确保后端解析逻辑和前端一致。最好前后端共用一份协议说明，并用同一组测试用例覆盖，避免两边个自发挥。

第五，尽量用成熟的第三方库。如果项目不太讲究自研，可以用js-cookie这类库来做cookie的基础读写，再在其上封装子cookie逻辑，比自己手撸document.cookie靠谱得多。基础能力交给经过验证的库，业务封装留在自己手里，责任边界清晰。

5.4 最后的小提醒

说道底，子cookie是个"看起来简单、用起来坑多"的方案。它没有标准实现，完全靠约定，适合处理那些必须放在cookie里、又不想占太多名额的轻量数据。决定用它之前，先问自己三个问题：这些数据必须跟请求走吗？合并成一个cookie后，我对它们的管理逻辑还清晰吗？前后端解析约定能保持一致吗？三个问题都回答"是"，再用不迟。

至于面试里被问到"子cookie有什么用"，我的建议是别去背那些八股答案，把这里的实际场景讲清楚，比空谈概念有用得多。存储这事儿，从来不是选最先进的方案，而是选最合适当下约束的方案。子cookie至今没消失，就是因为它在一个特定角落里，确实还有别的方案暂时替代不了的位置。