很多人在调试网页或开发接口时，会看到 Set-Cookie 这个字段，然后下意识地以为它是请求头的一部分。其实这是一个常见的误解。Set-Cookie 并不是 HTTP 请求头，而是服务器返回给浏览器的响应头。
响应头里的“指令”
当用户登录一个网站，比如购物平台，服务器验证账号密码后，会在响应中加入 Set-Cookie 字段，告诉浏览器：“记住这个用户的登录状态”。浏览器收到这个响应后，就会把对应的 Cookie 保存下来，后续每次访问该站点时，自动通过请求头中的 Cookie 字段发送回去。
举个例子，服务器返回的响应头可能是这样的：
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sessionid=abc123; Path=/; HttpOnly
Set-Cookie: theme=dark; Expires=Wed, 01 Jan 2025 00:00:00 GMT
<html><body>登录成功</body></html>这里出现了两个 Set-Cookie，说明服务器要设置多个 Cookie。注意，这些是响应头，出现在服务器的“回信”里，而不是客户端发出的请求中。
请求头里的 Cookie 才是“自报家门”
接下来你刷新页面，浏览器就会在新的请求头里带上这些信息：
GET /home HTTP/1.1
Host: example.com
Cookie: sessionid=abc123; theme=dark这才是真正的请求头字段 Cookie，用来向服务器证明“我之前登录过”。可以理解为：响应头用 Set-Cookie 发令牌，请求头用 Cookie 交令牌。
为什么容易搞混？
有些抓包工具（比如浏览器开发者工具）在展示请求时，会把当前请求携带的 Cookie 也列出来，甚至显示成类似 Cookie: ... 和 Set-Cookie: ... 混在一起的样子，导致初学者误以为 Set-Cookie 是发出去的。其实只要分清方向——谁发给谁，就能理清楚：Set-Cookie 只能由服务器设置，只能出现在响应中。
在网络安全领域，搞清楚这一点很重要。比如防范 CSRF 或 Cookie 劫持时，必须明白哪些头是客户端可控的，哪些是服务端下发的。Set-Cookie 是服务端控制的响应行为，前端 JavaScript 即使用 document.cookie 设置，底层也是浏览器模拟响应逻辑来写入，不会生成名为 Set-Cookie 的请求头。