面试题手册

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。写段代码Set-Cookie: sessionId=abc; Path=/; Secure; HttpOnly; SameSite=LaxCookie: sessionId=abc

防止 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 是否轮换。写段代码Set-Cookie: __Host-token=abc; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=1800

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。写段代码Set-Cookie: session=abc; Secure; HttpOnly; SameSite=Lax; Path=/Set-Cookie: iframe_token=xyz; Secure; HttpOnly; SameSite=None; Path=/

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，必须由服务端设置。写段代码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}`;}

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，导致子域风险放大。写段代码Set-Cookie: __Host-session=abc; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600

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。写段代码document.cookie = 'sid=abc; Path=/; Secure; SameSite=Lax';// 跨站且必须携带时：document.cookie = 'sso=abc; Path=/; Secure; SameSite=None';

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 分开命名和作用域，排查时也更清楚。写段代码Set-Cookie: sid=abc; Domain=example.com; Path=/; HttpOnly; Secure; SameSite=LaxSet-Cookie: admin=xyz; Path=/admin; HttpOnly; Secure; SameSite=Strict

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 就该清理。写段代码function cookieBytes() { return new Blob([document.cookie]).size;}if (cookieBytes() > 2048) { console.warn('Cookie too large:', cookieBytes());}

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。写段代码// Express 中 Session 存入 Redisconst 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 }}));

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 失效。写段代码// 服务端设置两种 Cookieres.setHeader('Set-Cookie', [ 'sid=abc123; HttpOnly; Secure; SameSite=Lax', // Session Cookie 'theme=dark; Max-Age=31536000; HttpOnly; SameSite=Lax' // Persistent Cookie]);