当用户通过浏览器第一次访问服务器的时候，服务器肯定是不知道他的身份的。所以，就要创建一个独特的身份标识数据，格式是“key=value”，然后放进 Set-Cookie 字段里，随着响应报文一同发给浏览器。

浏览器收到响应报文，看到里面有 Set-Cookie，知道这是服务器给的身份标识，于是就保存起来，下次再请求的时候就自动把这个值放进 Cookie 字段里发给服务器。

因为第二次请求里面有了 Cookie 字段，服务器就知道这个用户不是新人，之前来过，就可以拿出 Cookie 里的值，识别出用户的身份，然后提供个性化的服务。

不过因为服务器的“记忆能力”实在是太差，一张小纸条经常不够用。所以，服务器有时会在响应头里添加多个 Set-Cookie，存储多个“key=value”。但浏览器这边发送时不需要用多个 Cookie 字段，只要在一行里用“;”隔开就行

从这张图中我们也能够看到，Cookie 是由浏览器负责存储的，而不是操作系统。所以，它是“浏览器绑定”的，只能在本浏览器内生效。

如果你换个浏览器或者换台电脑，新的浏览器里没有服务器对应的 Cookie，就好像是脱掉了贴着纸条的衣服，“健忘”的服务器也就认不出来了，只能再走一遍 Set-Cookie 流程

原理拆解： Cookie 循环包含下发、保存、匹配和回传四步。服务器用 Set-Cookie 分别创建记录；浏览器按来源及属性保存，并在后续请求的主机、路径、安全条件匹配时生成 Cookie 请求头。服务器通常只把其中的随机会话标识当作索引，再到会话存储中查询用户资料，而不是把可信权限直接交给客户端决定。

最小验证： 运行以下 Node.js 程序，再访问 http://localhost:3000/。输入是连续两次浏览器请求，要验证第一次响应下发 sid，刷新后浏览器自动回传。

const http = require('node:http');

http.createServer((req, res) => {
  const cookies = Object.fromEntries(
    (req.headers.cookie || '').split('; ')
      .filter(Boolean)
      .map(item => {
        const i = item.indexOf('=');
        return [item.slice(0, i), item.slice(i + 1)];
      })
  );

  if (!cookies.sid) {
    res.setHeader('Set-Cookie', [
      'sid=a8f31; Path=/; HttpOnly; SameSite=Lax',
      'theme=dark; Path=/; SameSite=Lax'
    ]);
  }
  res.setHeader('Content-Type', 'text/plain; charset=utf-8');
  res.end(cookies.sid ? `recognized:${cookies.sid}` : 'first visit');
}).listen(3000, () => console.log('http://localhost:3000/'));

首次页面显示 first visit，刷新后预期显示 recognized:a8f31。数组中的两个值会生成两个 Set-Cookie 响应字段；浏览器回传时通常形成类似 sid=a8f31; theme=dark 的请求头。解析时以第一个 = 为分界，避免值中存在 = 时被错误截断。

边界与排查： 浏览器只发送满足作用域和策略的记录，因此“已经保存”不保证每个请求都携带。隐私模式、清除站点数据、更换浏览器或设备都会打断关联；禁用或拦截 Cookie 也会让示例持续停留在首次访问。可在开发者工具的 Network 中分别检查响应的 Set-Cookie 和下一次请求的 Cookie，再到站点存储面板核对域、路径、有效期及阻止原因。服务端还应把未知、过期或伪造的会话标识视为未登录。