服务端2026年5月30日 01:00
什么是 Cookie？它的工作原理和用途是什么？Cookie 是浏览器保存的一小段键值数据，通常用来让 HTTP 这种“无状态协议”记住用户状态。流程很简单：服务端在响应里用 `Set-Cookie` 下发 Cookie，浏览器按 Domain、Path、Expires、SameSite 等规则保存；之后访问匹配的地址时，浏览器会自动把 Cookie 放进 `Cookie` 请求头发回服务端。它常用于登录会话、用户偏好、购物车和统计分析。敏感会话 Cookie 一般要配 `Secure`、`HttpOnly`、`SameSite`，否则容易被窃取或被跨站请求滥用。
## 追问
### Cookie 和 localStorage 有什么区别？
Cookie 会随匹配请求自动发送给服务器，适合会话识别；localStorage 只在浏览器本地保存，不会自动进请求头，适合非敏感前端数据。
### Session Cookie 和持久 Cookie 有什么区别？
不设置 `Expires` 或 `Max-Age` 的通常是会话 Cookie，浏览器会话结束后失效；设置了过期时间的是持久 Cookie。
### Cookie 为什么有安全风险？
因为它可能代表登录态。被 XSS 读走会导致会话劫持，被 CSRF 利用会让浏览器自动带着 Cookie 发起恶意请求。
### SameSite、HttpOnly、Secure 分别解决什么问题？
`SameSite` 缓解 CSRF，`HttpOnly` 防止脚本读取，`Secure` 限制只走 HTTPS。
## 写段代码
```http
Set-Cookie: sessionId=abc; Path=/; Secure; HttpOnly; SameSite=Lax
Cookie: sessionId=abc
```标签
Cookie
Cookie（也称为网页cookie、浏览器cookie）是由网站创建的小型文本文件，当用户浏览该网站时，它被存储在用户的设备上。Cookie 的主要作用是帮助网站记住关于您的访问信息，比如登录状态、用户偏好设置、购物车中的物品等，从而在您再次访问网站时能够提供更个性化的用户体验。
服务端2026年5月30日 01:00
Cookie 的 Secure、HttpOnly、SameSite 有什么区别？如何防止被窃取？防止 Cookie 被窃取，核心是把“传输、读取、跨站发送、作用域”四件事管住：`Secure` 只允许 HTTPS 传输，降低中间人窃听风险；`HttpOnly` 禁止 JavaScript 读取，降低 XSS 偷 Cookie 的风险；`SameSite` 控制跨站请求是否带 Cookie，缓解 CSRF；`Domain` 和 `Path` 缩小发送范围。敏感登录态建议服务端设置 Cookie，不把 token 暴露给前端脚本，并优先使用 `__Host-` 前缀来避免子域覆盖。
## 追问
### Secure 和 HttpOnly 有什么区别？
Secure 管传输，只保证 Cookie 不走普通 HTTP；HttpOnly 管读取，防止 `document.cookie` 直接拿到敏感值。
### Path 能当安全边界吗？
不能。Path 主要控制发送范围，不应把它当权限隔离。真正的权限判断必须在服务端做。
### 为什么推荐 __Host- 前缀？
它要求 `Secure`、`Path=/`，且不能设置 `Domain`，能避免子域种下同名 Cookie 覆盖主站会话。
### 实战里如何排查 Cookie 被窃取？
先看是否缺 `HttpOnly` 或 `Secure`，再查 XSS、第三方脚本、过宽 Domain，以及登录后 sessionId 是否轮换。
## 写段代码
```http
Set-Cookie: __Host-token=abc; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=1800
```服务端2026年5月30日 01:00
SameSite Cookie 如何防止 CSRF？Strict、Lax、None 怎么选？SameSite 是 `Set-Cookie` 的属性，用来决定 Cookie 是否会随跨站请求发送。它能缓解 CSRF，是因为 CSRF 依赖“用户已登录，浏览器自动带上目标站 Cookie”。当 Cookie 设置为 `Strict` 或多数情况下的 `Lax` 时，恶意站点发起的跨站 POST、iframe、图片等请求通常拿不到登录态。常规业务优先用 `Lax`；高敏感操作用 `Strict`；确实需要第三方嵌入或跨站登录时才用 `None`，并且必须同时加 `Secure`。
## 追问
### Lax 会完全禁止跨站 Cookie 吗？
不会。跨站顶级导航的安全方法，比如用户点击链接发起 GET，仍可能携带 Cookie，所以它更像折中方案。
### SameSite=None 为什么必须配 Secure？
因为 None 允许跨站携带 Cookie，如果不用 HTTPS，Cookie 更容易在链路上泄露，现代浏览器也要求 `None; Secure` 组合使用。
### 有 SameSite 还需要 CSRF Token 吗？
高风险写操作仍建议保留 Token。SameSite 是浏览器策略，Token 是服务端校验，两者叠加更稳。
### 项目里怎么选默认值？
登录态默认 `Lax`；支付确认、改密码这类敏感 Cookie 用 `Strict`；第三方登录回调、嵌入式应用再评估 `None; Secure`。
## 写段代码
```http
Set-Cookie: session=abc; Secure; HttpOnly; SameSite=Lax; Path=/
Set-Cookie: iframe_token=xyz; Secure; HttpOnly; SameSite=None; Path=/
```服务端2026年5月30日 01:00
如何在 JavaScript 中设置、读取和删除 Cookie？JavaScript 操作 Cookie 主要靠 `document.cookie`。读取时它返回当前页面可访问的 Cookie 字符串；设置时一次只能写入一个 `name=value`，不会清空其他 Cookie；删除本质是把同名 Cookie 的过期时间设为过去。实际开发要注意两点：值要用 `encodeURIComponent` 编码，删除时 `Path`、`Domain` 要和设置时一致，否则看起来执行了，其实没删掉。`HttpOnly` Cookie 不能被 JavaScript 读取或设置，只能由服务端通过 `Set-Cookie` 下发。
## 追问
### document.cookie = xxx 会覆盖所有 Cookie 吗？
不会。它只会新增或更新当前这一个 Cookie。读取 `document.cookie` 才会看到多个 Cookie 拼成的字符串。
### 为什么删除 Cookie 有时不生效？
大概率是 `Path` 或 `Domain` 不一致。比如设置时用了 `Path=/app`，删除时只写 `Path=/`，浏览器会认为它们不是同一个 Cookie。
### 为什么要编码 Cookie 值？
Cookie 值里如果有空格、分号、中文等特殊字符，可能导致解析错误。写入用 `encodeURIComponent`，读取用 `decodeURIComponent`。
### JavaScript 能设置 HttpOnly 吗？
不能。`HttpOnly` 的目的就是禁止脚本访问 Cookie，必须由服务端设置。
## 写段代码
```javascript
function setCookie(name, value, maxAge, path = '/') {
document.cookie = `${name}=${encodeURIComponent(value)}; Max-Age=${maxAge}; Path=${path}`;
}
function getCookie(name) {
return document.cookie.split('; ').find(v => v.startsWith(name + '='))
?.split('=').slice(1).join('=') || null;
}
function deleteCookie(name, path = '/') {
document.cookie = `${name}=; Max-Age=0; Path=${path}`;
}
```服务端2026年5月30日 01:00
Cookie 有哪些安全风险？如何防范 XSS、CSRF 和窃取？Cookie 的主要风险有四类：XSS 读取 `document.cookie`、CSRF 借浏览器自动带 Cookie 发请求、HTTP 明文传输被中间人截获，以及 Domain/Path 配置过宽导致 Cookie 被子域或无关路径滥用。敏感 Cookie 应由服务端设置，并组合使用 `HttpOnly`、`Secure`、`SameSite=Lax/Strict`、短有效期和签名校验。注意：SameSite 能降低 CSRF 风险，但高风险写操作仍建议校验 CSRF Token 或 Origin/Referer。
## 追问
### HttpOnly 能彻底防住 XSS 吗？
不能。它只是禁止 JavaScript 读取 Cookie，不能阻止脚本执行，也不能阻止恶意脚本发起带 Cookie 的请求。
### SameSite=Lax 和 Strict 怎么选？
普通登录态多用 Lax，兼顾外部链接跳转体验；支付、后台管理等高风险场景可用 Strict。
### Cookie 被篡改怎么办？
不要信任客户端值。服务端应对 Cookie 做签名或只存 sessionId，真实权限状态放服务端。
### 实际项目里最容易漏什么？
`SameSite=None` 忘记配 `Secure`，浏览器会拒绝或异常处理；另一个坑是把主站 session 设置到 `.example.com`，导致子域风险放大。
## 写段代码
```http
Set-Cookie: __Host-session=abc; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
```服务端2026年5月30日 01:00
Cookie 浏览器兼容有哪些差异？如何处理？Cookie 浏览器兼容差异主要集中在容量限制、SameSite 默认值、第三方 Cookie、隐私保护策略和过期时间。现在不能再假设“所有浏览器都会长期保存并发送 Cookie”：Safari 的 ITP、Firefox 的 ETP、Chrome 的第三方 Cookie 收紧都会影响跨站登录、埋点和广告归因。处理思路是默认一方 Cookie、SameSite=Lax、Secure 开启，跨站场景单独设计降级方案。
## 追问
### 各浏览器容量差异要怎么记？
单个 Cookie 通常按 4KB 估算，每个域名数量上限各家不同。面试里不必背精确数字，关键是不要依赖“能存很多”，超过少量会话字段就该换存储方案。
### SameSite=None 为什么必须配 Secure？
因为 `SameSite=None` 表示允许跨站发送 Cookie，风险更高。现代浏览器要求它只能在 HTTPS 下配合 `Secure` 使用，否则可能直接拒收。
### Safari ITP 对业务影响最大在哪里？
跨站追踪、第三方登录态和长期归因最容易出问题。即使代码没变，Cookie 也可能被限制有效期或阻止发送，所以要用真实 Safari 和隐私模式测试。
### 第三方 Cookie 被禁后怎么办？
优先改成一方登录态；确实跨域时，用 OAuth 跳转、服务端会话、postMessage 或浏览器提供的新 API，而不是继续依赖隐藏 iframe 写 Cookie。
## 写段代码
```javascript
document.cookie = 'sid=abc; Path=/; Secure; SameSite=Lax';
// 跨站且必须携带时：
document.cookie = 'sso=abc; Path=/; Secure; SameSite=None';
```服务端2026年5月30日 01:00
Cookie 的 Domain 和 Path 有什么作用？如何设置？Cookie 的 Domain 决定哪些域名会收到它，Path 决定哪些路径会收到它。默认不写 Domain 时，Cookie 通常只属于当前 host；写成父域如 `example.com` 时，子域也可能共享。Path 是路径前缀匹配，不是权限隔离，主要用于减少无关请求携带 Cookie。正确做法是按最小范围设置，登录态、后台、支付、静态资源不要混用一个宽泛 Cookie。
## 追问
### 不写 Domain 和写 Domain 有什么区别？
不写 Domain 更收敛，通常只给当前主机使用。写父域会扩大到子域，适合 SSO，但也扩大了泄露和冲突范围。现在前导点 `.example.com` 基本被忽略，关键是域本身是否合法。
### Path=/api 能防止前端 JS 读取 Cookie 吗？
不能。Path 控制请求是否携带 Cookie，不是安全边界。要防 JS 读取，应设置 `HttpOnly`；要跨站防护，还要配合 `SameSite` 和 CSRF 方案。
### Path 的匹配规则是什么？
它是前缀匹配。`Path=/admin` 会匹配 `/admin` 和 `/admin/user`，但设计时最好写清楚边界，避免 `/admin-old` 这类路径造成误判。
### 实际项目怎么设置？
会话 Cookie 尽量只给需要鉴权的域和路径；静态资源放到无 Cookie 域名；管理后台、支付、开放 API 分开命名和作用域，排查时也更清楚。
## 写段代码
```http
Set-Cookie: sid=abc; Domain=example.com; Path=/; HttpOnly; Secure; SameSite=Lax
Set-Cookie: admin=xyz; Path=/admin; HttpOnly; Secure; SameSite=Strict
```服务端2026年5月30日 01:00
Cookie 性能如何优化？怎样减少大小和数量？Cookie 性能优化的核心是少带、少存、少匹配。因为同域请求会自动携带匹配 Cookie，Cookie 越多，请求头越大，移动网络和高并发接口越容易被拖慢。实战里优先把会话凭证保留在 Cookie，把偏好、缓存、草稿这类非敏感数据迁到 localStorage、sessionStorage 或 IndexedDB；同时收窄 Domain、Path，避免静态资源和无关接口也背着 Cookie 跑。
## 追问
### Cookie 为什么会影响接口性能？
每次 HTTP 请求都会带上匹配的 Cookie。即使只是请求一张图片，只要域名和路径匹配，也可能多传几 KB 请求头。HTTP/2 有 HPACK 压缩，但不能把设计不当的 Cookie 变成零成本。
### 减少 Cookie 大小有哪些做法？
只存必要字段，键名和值都尽量短；多个小偏好可以合并成一个值，但不要把大对象硬塞进去。超过 4KB 或频繁变化的数据不适合放 Cookie。
### Domain 和 Path 怎么配合性能优化？
Domain 不要随手设成 `.example.com`，Path 也不要一律 `/`。例如后台令牌只给 `admin.example.com` 和 `/admin`，API Cookie 只给 `/api`，静态资源域名最好不设置 Cookie。
### 项目里常见坑是什么？
分析、AB 实验、灰度标记容易越积越多，最后每个请求都多带一串历史垃圾。上线前可以在网关或浏览器 DevTools 里看 Request Headers，超过 2KB 就该清理。
## 写段代码
```javascript
function cookieBytes() {
return new Blob([document.cookie]).size;
}
if (cookieBytes() > 2048) {
console.warn('Cookie too large:', cookieBytes());
}
```服务端5月29日 01:22
Cookie 和 Session 有什么区别？何时用 Cookie，何时用 Session？Cookie 存在客户端浏览器，每次请求自动携带，上限约 4KB，可被用户查看和篡改；Session 存在服务端（内存/Redis/数据库），客户端只持有 Session ID（通常通过 Cookie 传递），数据大小无硬性限制，安全性更高。核心区别是状态存储位置：Cookie 是客户端状态，Session 是服务端状态。选择依据：非敏感偏好数据（主题、语言）用 Cookie；登录态、权限等敏感数据用 Session。Session 的局限在于服务端需存储状态，分布式场景需用 Redis 等集中式存储共享 Session，否则粘性Session限制了水平扩展。JWT 是第三条路：将状态编码进 Token 本身，服务端无状态验证签名即可，但 Token 体积大且无法主动失效。
## 追问
**Session ID 被窃取会怎样？如何防范？**
攻击者可用截获的 Session ID 冒充用户（Session 劫持）。防范：Cookie 标记 HttpOnly+Secure，绑定 IP/UA 校验，使用 SameSite 属性，Session 定期轮换 ID，设置合理超时。
**分布式系统中 Session 如何共享？**
三种方案：1) 粘性 Session（Nginx ip_hash），简单但不利于负载均衡；2) 集中存储（Redis/Memcached），最常用；3) Session 复制（Tomcat 集群广播），数据量大时性能差。
**JWT 相比 Session 的优劣？**
优势：无状态，服务端不存数据，天然支持分布式。劣势：无法主动注销（需黑名单机制又回到有状态），Token 体积大于 Session ID，续期机制复杂（双 Token 方案）。
**Cookie 被禁用怎么办？**
Session ID 可通过 URL 参数传递（;jsessionid=xxx），但会暴露在日志和 Referer 中，安全性差。更推荐在登录页提示用户启用 Cookie。
## 写段代码
```javascript
// Express 中 Session 存入 Redis
const session = require('express-session');
const RedisStore = require('connect-redis');
app.use(session({
store: new RedisStore({ client: redisClient }),
secret: 'your-secret',
resave: false,
cookie: { httpOnly: true, secure: true, maxAge: 3600000 }
}));
```服务端5月29日 01:21
Session Cookie 和 Persistent Cookie 有什么区别？Session Cookie 不设 Expires 和 Max-Age 属性，浏览器将其存在内存中，关闭浏览器即消失；Persistent Cookie 设有明确的过期时间，存储在磁盘上，过期前跨会话持久存在。服务端通过 Set-Cookie 响应头控制类型：不设过期属性是 Session Cookie，设 Max-Age 或 Expires 则为 Persistent Cookie。安全层面两者都应标记 HttpOnly 和 Secure，Persistent Cookie 因长期驻留磁盘更易被窃取，敏感数据应避免持久化。SameSite 属性（Strict/Lax/None）对两者同样适用，防止 CSRF 攻击。
## 追问
**浏览器关闭后 Session Cookie 一定被清除吗？**
不一定。现代浏览器有恢复会话功能（如 Chrome 的继续浏览上次打开的网页），会将 Session Cookie 写入磁盘以便恢复，实际表现等同于 Persistent Cookie。依赖关闭即清除做安全假设是不可靠的。
**Max-Age 和 Expires 有什么区别？**
Max-Age 是相对秒数，从收到 Cookie 时起算；Expires 是绝对时间点，依赖客户端时钟。Max-Age 优先级更高（RFC 6265），两者都不设则为 Session Cookie。
**Session Cookie 能存多少数据？**
和 Persistent Cookie 一样受 4KB 限制，区别仅在于生命周期，不在容量。大量数据应改用 localStorage 或 IndexedDB。
**如何强制 Session Cookie 在标签页关闭时清除？**
无法可靠实现。可用的替代方案：用 sessionStorage（标签页级）或服务端维护有效期并主动使 Session 失效。
## 写段代码
```javascript
// 服务端设置两种 Cookie
res.setHeader('Set-Cookie', [
'sid=abc123; HttpOnly; Secure; SameSite=Lax', // Session Cookie
'theme=dark; Max-Age=31536000; HttpOnly; SameSite=Lax' // Persistent Cookie
]);
```