1. 项目概述为什么我们还在聊Cookie在Web开发的世界里Cookie就像空气一样无处不在却又常常被我们忽视。作为一名前端开发者我几乎每天都要和它打交道无论是处理用户登录状态、记录用户偏好还是做简单的数据追踪。尽管现在有了LocalStorage、SessionStorage甚至IndexedDB这些更现代的客户端存储方案但Cookie凭借其与HTTP协议深度绑定的特性——尤其是服务器端可读写、可设置过期时间、可限定路径和域这些能力——在许多场景下依然是不可替代的。特别是涉及到需要与后端服务API进行身份认证交互时Cookie几乎是标准答案。最近在带新人或者review代码时我发现很多朋友对Cookie的操作还停留在非常基础的document.cookie赋值和字符串切割上。一旦遇到需要设置HttpOnly、Secure、SameSite属性或者需要处理路径、域等复杂情况时就容易手忙脚乱写出容易出错的代码。网上的资料也良莠不齐很多只是简单罗列API缺乏实际场景的串联和避坑指南。所以我决定结合自己这些年踩过的坑和积累的最佳实践系统地整理一份关于JavaScript操作Cookie的指南。这不仅仅是一个API列表更是一份从原理到实战包含“为什么这么做”和“怎么做得更好”的实操手册。无论你是刚入门的前端新人还是想巩固基础的中级开发者相信都能从中找到对你有用的东西。2. Cookie核心原理与基础操作解析2.1 Cookie的本质它不只是个“小甜饼”要玩转Cookie的API首先得理解它到底是什么。从技术上讲Cookie是服务器发送到用户浏览器并保存在本地的一小块数据。浏览器会存储它并在后续向同一服务器发起的请求中自动携带它。这个“自动携带”是关键也是Cookie区别于其他存储方案的核心。一个Cookie由以下几部分构成名称Name和值Value这是最核心的键值对。值通常是字符串但理论上可以存储任何可以被字符串化的内容不过有大小限制通常每个Cookie不超过4KB每个域名下的Cookie总数也有限制不同浏览器在50-150个不等。域Domain指定Cookie对哪个域名有效。如果不设置默认为当前文档的源不包括子域名。如果设置为.example.com则对www.example.com、api.example.com等都有效。这里有个大坑你不能设置Cookie的域为当前域名的上级域名例如在www.a.com下设置域为.com是无效且危险的。路径Path指定Cookie在哪个路径下有效。例如路径设置为/admin的Cookie在访问/admin/users或/admin/settings时会被发送但在访问/home时则不会。默认是当前文档的路径。过期时间Expires/Max-AgeExpires指定一个具体的GMT格式的过期日期时间。new Date().toUTCString()是生成它的好帮手。Max-Age指定Cookie从设置开始存活的秒数。优先级高于Expires。注意如果两者都不设置Cookie就是一个“会话Cookie”浏览器关闭时它就会被清除。安全标志Secure如果设置了这个属性Cookie只会在通过HTTPS协议发送请求时才会被携带。在如今全站HTTPS的趋势下对于涉及敏感信息如Session ID的Cookie设置Secure是必须的安全实践。HttpOnly标志这是一个非常重要的安全属性。如果设置JavaScript的document.cookieAPI将无法读取或修改这个Cookie。它只能由服务器通过Set-Cookie响应头来设置并由浏览器在请求时自动发送。这能有效防御XSS跨站脚本攻击窃取Cookie。所以身份认证的令牌如Session ID必须被标记为HttpOnly。SameSite标志用来防止CSRF跨站请求伪造攻击。它有三个值Strict最严格完全禁止第三方Cookie。即从A网站跳转到B网站B网站发往A的请求不会携带A的Cookie。Lax现代浏览器的默认值相对宽松在安全的外链跳转如a链接和页面初始加载如通过URL输入地址时会发送Cookie但在form提交、iframe加载、或通过fetch/XMLHttpRequest发起的跨站请求中不发送。None允许跨站发送Cookie但必须同时设置Secure属性即必须使用HTTPS。理解这些属性是正确操作Cookie的前提。很多奇怪的Bug比如“登录状态为什么突然没了”、“这个Cookie为什么在这个页面读不到”根源都在于对这些属性的设置理解不透彻。2.2 原生APIdocument.cookie的“朴素”操作JavaScript操作Cookie最原始的方式就是通过document.cookie。它是一个特殊的属性读取和写入的行为并不直观。读取所有Cookieconst allCookiesString document.cookie; // 例如”usernameJohn; themedark; sessionIdabc123“读取操作返回的是一个字符串里面包含了当前文档可访问的所有Cookie受域和路径限制每个Cookie以名称值的形式出现之间用分号和空格分隔。你需要自己解析这个字符串。写入/设置一个Cookiedocument.cookie “usernameJohn Doe; expiresFri, 31 Dec 2024 23:59:59 GMT; path/; Secure; SameSiteLax”;写入操作不是替换整个document.cookie字符串而是创建一个或更新一个特定的Cookie。你赋值的是一个符合Set-Cookie头部格式的字符串。如果设置的Cookie名称已存在且域和路径匹配则会更新其值否则会新建一个。删除一个Cookie原生API没有直接的删除方法。删除的本质是设置该Cookie的过期时间为一个过去的时间。document.cookie “username; expiresThu, 01 Jan 1970 00:00:00 GMT; path/”; // 注意这里值可以设为空但必须确保域、路径等属性与要删除的Cookie完全一致否则可能删不掉。原生API的痛点解析繁琐每次读取都要手动分割字符串、解码值可能是encodeURIComponent编码过的。设置复杂构造一个包含多个属性的字符串容易出错特别是日期格式。容易遗漏属性忘记设置path/可能导致Cookie只在当前页面路径下有效。无法处理HttpOnly这是由设计决定的是安全特性不是缺点。正因为这些痛点在实际项目中我们很少直接裸用document.cookie而是会进行一层封装或者使用成熟的第三方库。3. 实战封装打造自己的Cookie工具库虽然有很多优秀的第三方库比如js-cookie但自己动手封装一个简易的工具函数对于理解Cookie的细节非常有帮助。下面我分享一个我常用的、在生产环境也验证过的封装方案。3.1 基础工具函数实现/** * Cookie操作工具类 */ const CookieUtils { /** * 设置Cookie * param {string} name - Cookie名称 * param {string} value - Cookie值 * param {Object} [options] - 配置选项 * param {number} [options.maxAge] - 存活秒数 * param {Date|string} [options.expires] - 过期时间Date对象或GMT字符串 * param {string} [options.path] - 路径默认 / * param {string} [options.domain] - 域 * param {boolean} [options.secure] - 是否仅HTTPS * param {Strict|Lax|None} [options.sameSite] - SameSite属性 */ set(name, value, options {}) { // 1. 对名称和值进行编码防止特殊字符如分号、空格破坏Cookie格式 const encodedName encodeURIComponent(name); const encodedValue encodeURIComponent(value); let cookieString ${encodedName}${encodedValue}; // 2. 处理过期时间优先使用maxAge其次expires if (options.maxAge typeof options.maxAge number) { cookieString ; max-age${options.maxAge}; } else if (options.expires) { let expiresDate; if (options.expires instanceof Date) { expiresDate options.expires; } else { // 尝试解析传入的字符串如果失败则按当前时间计算 expiresDate new Date(options.expires); if (isNaN(expiresDate.getTime())) { console.warn(Invalid expires date provided for cookie ${name}. Using default.); expiresDate new Date(Date.now() 24 * 60 * 60 * 1000); // 默认1天后过期 } } cookieString ; expires${expiresDate.toUTCString()}; } // 如果两者都没提供就是一个会话Cookie浏览器关闭即失效 // 3. 处理路径默认设为根路径确保全站可用 const path options.path || /; cookieString ; path${path}; // 4. 处理域 if (options.domain) { // 简单校验不能设置非当前域或其子域的域 const currentHost window.location.hostname; if (currentHost options.domain || currentHost.endsWith(.${options.domain})) { cookieString ; domain${options.domain}; } else { console.error(Cannot set cookie for domain ${options.domain} on host ${currentHost}.); return false; } } // 5. 安全属性 if (options.secure) { cookieString ; Secure; } // 6. SameSite属性 if (options.sameSite) { const sameSite options.sameSite.charAt(0).toUpperCase() options.sameSite.slice(1).toLowerCase(); if ([Strict, Lax, None].includes(sameSite)) { cookieString ; SameSite${sameSite}; // SameSiteNone 必须配合 Secure if (sameSite None !options.secure) { console.warn(Cookie ${name} set with SameSiteNone but without Secure. This may be rejected by modern browsers.); } } else { console.warn(Invalid SameSite value ${options.sameSite} for cookie ${name}. Ignored.); } } // 7. 写入Cookie document.cookie cookieString; return true; }, /** * 获取Cookie值 * param {string} name - Cookie名称 * returns {string|null} - Cookie值不存在则返回null */ get(name) { // 编码名称以匹配存储时的格式 const encodedName encodeURIComponent(name); // 使用正则表达式精确匹配避免部分匹配例如找user却匹配到了username const match document.cookie.match(new RegExp((?:^|;\\s*)(${encodedName})([^;]*))); // 如果匹配到解码后返回 return match ? decodeURIComponent(match[2]) : null; }, /** * 获取所有Cookie以对象形式返回 * returns {Object} - 所有Cookie的键值对 */ getAll() { const cookies {}; if (!document.cookie) { return cookies; } // 分割字符串注意要去掉空格 const cookieArray document.cookie.split(; ); for (const cookie of cookieArray) { const [encodedName, encodedValue] cookie.split(); if (encodedName) { const name decodeURIComponent(encodedName); const value decodeURIComponent(encodedValue || ); cookies[name] value; } } return cookies; }, /** * 删除Cookie * param {string} name - Cookie名称 * param {Object} [options] - 必须与设置时的path/domain一致才能删除成功 * param {string} [options.path] - 路径默认 / * param {string} [options.domain] - 域 */ remove(name, options {}) { // 删除就是设置一个过去的过期时间 const deleteOptions { ...options, expires: new Date(0), // 1970-01-01 maxAge: -1 // 有些浏览器也支持maxAge为负数 }; // 值设为空 this.set(name, , deleteOptions); } }; // 使用示例 CookieUtils.set(userToken, eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..., { maxAge: 7 * 24 * 60 * 60, // 7天 path: /, secure: true, sameSite: Lax }); const token CookieUtils.get(userToken); // eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... const allCookies CookieUtils.getAll(); // { userToken: ..., theme: dark, ... } CookieUtils.remove(userToken, { path: / });3.2 封装中的关键细节与避坑指南编码与解码是必须的Cookie的值中不能包含分号;、逗号,、等号和空格。encodeURIComponent/decodeURIComponent可以安全地处理这些字符。很多初学者忘记编码导致存储的Cookie值被截断或解析错误。路径Path默认值应为/除非你有特殊需求比如某个Cookie只想让后台管理页面使用否则在设置Cookie时务必显式设置path/。如果不设置浏览器会默认使用当前页面的路径。假设你在/user/profile页面设置了一个没有指定path的Cookie那么在/根路径或者/product页面就读不到它这会引发非常隐蔽的Bug。删除操作必须匹配路径和域删除Cookie不是简单地设置一个空值。你必须确保调用remove时传入的path和domain如果有与当初设置这个Cookie时完全一致。否则你只是在创建一个新的、立即过期的Cookie而旧的Cookie依然存在。这是最常见的“删不掉Cookie”问题的根源。我的工具函数通过要求传入options参数来提醒开发者注意这一点。日期处理的鲁棒性在set函数中我对expires参数做了容错处理。如果传入一个无法解析的日期字符串会给出警告并使用一个默认的未来日期。在生产环境中更严格的做法可能是直接抛出错误强制调用者提供正确的格式。SameSiteNone 必须配合 Secure这是现代浏览器Chrome 80, Firefox 79等的强制要求。如果你的网站需要跨站使用Cookie例如在嵌入的iframe中或通过CORS请求必须同时设置SameSiteNone和Securetrue。我的封装里加入了警告提示。4. 进阶场景与第三方库应用4.1 典型应用场景深度剖析掌握了基础操作我们来看看Cookie在真实项目中的典型应用。这些场景能帮你更好地理解“为什么要用Cookie”以及“怎么用才对”。场景一用户身份认证与令牌管理这是Cookie最核心的用途。通常流程是用户登录前端将账号密码发给后端API。后端验证通过生成一个令牌如JWT通过Set-Cookie响应头将其设置到浏览器并标记为HttpOnly和Secure。此后浏览器在访问该域下的任何API时都会自动在请求头中带上这个Cookie。前端无需在JavaScript中手动处理这个令牌。这是HttpOnly带来的安全好处。前端需要判断登录状态时可以尝试访问一个受保护的API端点或者依赖后端在另一个非HttpOnly的Cookie如isLoggedIntrue或响应体中返回用户状态。关键点认证令牌必须HttpOnlySecure。前端不应也不能读取它。这是防御XSS的黄金法则。场景二用户偏好设置比如主题深色/浅色、语言、地区、表格每页显示条数等。这些信息不敏感且需要持久化即使关闭浏览器再打开设置依然有效。// 用户切换主题时 function switchTheme(theme) { CookieUtils.set(app_theme, theme, { maxAge: 365 * 24 * 60 * 60, // 保存一年 path: /, sameSite: Lax }); // ... 应用主题的UI逻辑 } // 应用初始化时 function initApp() { const savedTheme CookieUtils.get(app_theme) || light; applyTheme(savedTheme); }关键点这类Cookie可以设置较长的过期时间并且不需要HttpOnly因为前端JS需要读写它。场景三简单的跨页面状态传递在单页应用SPA大行其道的今天这个场景变少了但在多页应用MPA或SPA的某些特殊路由跳转中仍有价值。比如在A页面筛选了商品列表跳转到B页面时希望保持筛选条件。你可以把筛选参数序列化后存到Cookie里。// 页面A离开时 function onPageALeave(filterOptions) { const filterStr JSON.stringify(filterOptions); CookieUtils.set(product_filter, filterStr, { path: /products, // 只在产品相关页面有效 maxAge: 10 * 60 // 10分钟有效 }); } // 页面B加载时 function onPageBLoad() { const filterStr CookieUtils.get(product_filter); if (filterStr) { const filterOptions JSON.parse(filterStr); // ... 应用筛选条件 // 用完可以考虑删除避免下次进入还生效 CookieUtils.remove(product_filter, { path: /products }); } }关键点注意设置合适的path和较短的maxAge避免数据污染其他页面或长期残留。4.2 第三方库 js-cookie 的优劣与选用虽然我们自己封装了工具但了解并评估优秀的第三方库也是必备技能。js-cookie是目前最流行的Cookie操作库之一它的API设计非常简洁。安装与基本使用npm install js-cookie # 或直接通过CDN引入import Cookies from js-cookie; // 设置 Cookies.set(name, value, { expires: 7, path: /, secure: true, sameSite: strict }); // 读取 Cookies.get(name); // value Cookies.get(); // { name: value } // 删除 Cookies.remove(name, { path: / });js-cookie 的优势API极其简洁链式调用、默认值处理得很好开发者体验优秀。自动编码解码内部自动处理了encodeURIComponent/decodeURIComponent你存对象取出来就是对象它用了JSON序列化。良好的兼容性处理了旧浏览器的边缘情况。体积小巧压缩后只有几百字节。js-cookie 的“劣势”或注意事项默认路径js-cookie在设置Cookie时如果不指定path它默认使用的是当前页面的路径而不是根路径/。这和我们自己封装时强调的“默认设为/”不同更容易导致前面提到的“Cookie在某些页面找不到”的问题。使用时务必留意无法处理HttpOnly这是由浏览器安全策略决定的任何前端库都无法突破。对SameSiteNone的警告较新版本的js-cookie在你设置sameSite: None但未设置secure: true时会在控制台输出警告这一点很贴心。选型建议对于简单项目或快速原型直接使用js-cookie省时省力。对于中大型项目且有严格的规范要求可以考虑使用自己封装的工具库如本文的CookieUtils因为你可以完全控制默认行为如强制path/、添加符合自己业务逻辑的校验和日志。核心原则无论用哪个都要清晰理解其默认行为并根据你的应用场景明确设置每一个属性特别是path、secure和sameSite。5. 安全、性能与调试实战指南5.1 Cookie安全加固清单Cookie的安全性至关重要一旦泄露可能导致用户会话被劫持。以下是一份你必须遵守的安全清单敏感Cookie必须标记为 HttpOnly防止XSS攻击窃取。这主要靠后端在设置Set-Cookie响应头时完成。敏感Cookie必须标记为 Secure确保只在HTTPS连接中传输防止在明文HTTP中被窃听。同样主要靠后端设置。合理使用 SameSite 属性对于身份认证Cookie设置为Strict或Lax默认以防御CSRF攻击。Strict安全性最高但可能影响跨站跳转的体验比如从邮件链接点回网站需要重新登录。Lax是平衡安全与体验的好选择。只有当你的Cookie确实需要被第三方网站访问时例如嵌入的支付iframe、跨域单点登录才使用SameSiteNone并且必须同时设置Secure。设置合适的过期时间会话Cookie不设置expires或max-age在浏览器关闭时失效最安全。对于“记住我”功能可以设置一个较长的但非永久的过期时间如30天并定期刷新令牌。避免在Cookie中存储敏感数据Cookie在每次请求中都会发送体积过大会影响性能。更不要存储密码、信用卡号等明文信息。存储一个由服务器签名的、不可预测的令牌Session ID或JWT是更好的做法。防范Cookie篡改对于重要的Cookie后端应对其值进行签名例如使用HMAC。这样即使前端Cookie被恶意修改后端也能验证出来并拒绝请求。5.2 性能考量与最佳实践Cookie的另一个特点是它会随着每一个HTTP请求包括对图片、CSS、JS的请求自动发送到服务器。这带来了性能开销。精简Cookie数量和大小定期审计你的Cookie删除那些不再使用的。确保每个Cookie只存储必要的信息。记住每个域名下的Cookie总数和总大小是有限制的通常每个Cookie不超过4KB总数不超过50个左右。使用CDN和Cookie-less Domains对于静态资源图片、样式、脚本使用一个独立的、没有设置过Cookie的域名或子域名来提供。这样浏览器在请求这些资源时就不会携带主站的Cookie可以显著提升加载速度也利于CDN缓存。区分会话状态和本地偏好将必须在每次请求中携带的会话标识符小且必要与只在需要时读取的用户偏好可能较大分开存储。用户偏好可以考虑用LocalStorage存储只在应用初始化时读取一次。5.3 浏览器开发者工具调试技巧现代浏览器的开发者工具是调试Cookie的利器。Application面板Chrome/Edge或 Storage面板Firefox这里可以清晰地看到当前页面所有可访问的Cookie包括它们的名称、值、域、路径、过期时间、大小以及HttpOnly、Secure、SameSite等安全属性。你可以直接在这里编辑、删除Cookie模拟各种状态非常方便。Network面板查看任何一个请求在“Headers”标签页下找到“Request Headers”部分的Cookie字段可以看到浏览器实际发送了哪些Cookie。在“Response Headers”部分可以查看服务器通过Set-Cookie返回了哪些指令。这是验证Cookie设置是否生效的最佳方式。Console面板直接输入document.cookie可以快速查看当前可读的Cookie字符串。你也可以在这里执行我们封装的CookieUtils或Cookies库的方法进行测试。一个典型的调试流程用户反馈“登录状态丢失”。打开开发者工具 - Application - Cookies - 查看你的域名。检查认证Cookie例如sessionId是否存在HttpOnly、Secure属性是否正确过期时间是否已过。刷新页面在Network面板查看第一个文档请求确认Cookie请求头中是否携带了该sessionId。查看登录API的响应确认Set-Cookie头部是否正确返回并设置了新的Cookie。如果Cookie被设置了但没发送检查Path和Domain是否匹配当前请求的URL。6. 常见问题排查与解决方案实录在实际开发中你会遇到各种各样关于Cookie的“灵异事件”。下面是我总结的一些高频问题及其排查思路。6.1 问题速查表问题现象可能原因排查步骤与解决方案Cookie设置成功但在其他页面读不到1.Path不匹配设置时未指定path或path范围过窄。2.Domain不匹配设置了错误的或过窄的域。1. 在开发者工具Application面板检查该Cookie的Path和Domain属性。2. 确保设置Cookie时显式指定path/除非有特殊限制。3. 检查Domain设置是否正确通常不设置或设置为当前域的主域如.example.com。Cookie被浏览器拒绝设置不成功1.SameSiteNone未配合Secure现代浏览器强制要求。2.域名不合法尝试设置非当前域或其子域的Cookie。3.HTTPS页面设置非Secure Cookie部分浏览器如Chrome在HTTPS下可能限制非Secure Cookie。1. 检查Console是否有浏览器警告如关于SameSite的。2.确保SameSiteNone时一定同时设置Securetrue。3. 检查设置的Domain是否合法。4. 全站HTTPS环境下Cookie尽量都设置Secure。删除Cookie无效刷新后还在删除时Path/Domain与设置时不匹配。删除操作本质是设置一个过期的同名Cookie必须属性完全匹配才能覆盖。1. 确认删除代码中传入的path和domain如果有与设置时完全一致。2.最佳实践设置Cookie时就使用一致的、明确的Path如/删除时也传入同样的Path。本地开发localhost无法设置Cookie1.前端跨域请求API运行在不同端口或域名未正确配置CORS的credentials。2.后端Set-Cookie头格式问题。1. 前端fetch/axios请求需设置credentials: include。2. 后端CORS配置需允许凭证Access-Control-Allow-Credentials: true且Access-Control-Allow-Origin不能为通配符*必须是明确的来源。3. 检查后端返回的Set-Cookie头是否有效。Safari/移动端浏览器Cookie行为异常1.Safari的智能防跟踪ITP可能会限制第三方Cookie或某些情况下的第一方Cookie生命周期。2.浏览器隐私设置。1. 对于关键的身份Cookie考虑备用方案如将token也放在Authorization头中前端从非HttpOnly的Cookie或LocalStorage读取。2. 避免过度依赖客户端Cookie存储长期身份状态采用短期令牌定期刷新的机制。Cookie值包含特殊字符导致被截断存储前未进行编码。始终使用encodeURIComponent()对值进行编码读取时使用decodeURIComponent()解码。使用封装好的库如js-cookie可自动处理。6.2 跨域请求携带Cookie的深坑详解这是前后端分离架构下最常见的问题之一。假设你的前端运行在http://localhost:3000后端API在http://localhost:8080。前端需要做的使用fetch或axios等发起请求时必须显式声明携带凭证。// 使用 fetch fetch(http://localhost:8080/api/user, { method: GET, credentials: include // 这是关键默认是 same-origin }); // 使用 axios axios.get(http://localhost:8080/api/user, { withCredentials: true // 这是关键 });后端需要做的以Node.js Express为例必须正确配置CORS中间件。const express require(express); const cors require(cors); const app express(); const corsOptions { origin: http://localhost:3000, // 必须明确指定前端源不能用 * credentials: true // 允许携带凭证 }; app.use(cors(corsOptions)); // 或者手动设置头部 app.use((req, res, next) { res.header(Access-Control-Allow-Origin, http://localhost:3000); // 明确指定 res.header(Access-Control-Allow-Credentials, true); // 关键 res.header(Access-Control-Allow-Headers, Content-Type, Authorization); res.header(Access-Control-Allow-Methods, GET, POST, PUT, DELETE, OPTIONS); if (req.method OPTIONS) { return res.sendStatus(200); } next(); });核心要点当请求需要携带Cookie或其他凭证如HTTP认证时后端的Access-Control-Allow-Origin绝对不能是通配符*必须是具体的、请求来源的域名。同时Access-Control-Allow-Credentials必须为true。6.3 本地开发与生产环境差异处理本地开发环境localhost和生产环境yourdomain.com在Cookie处理上常有差异主要在于域Domain和安全Secure属性。策略建议环境变量配置将前端域名和后端API域名通过环境变量管理。动态设置Cookie属性// 在你的Cookie工具函数或配置中 const isProduction process.env.NODE_ENV production; const cookieDomain isProduction ? .yourdomain.com : localhost; const isSecure isProduction; // 生产环境用HTTPSSecure应为true CookieUtils.set(myCookie, value, { path: /, domain: cookieDomain, secure: isSecure, sameSite: isProduction ? Lax : None // 本地跨端口需要None });注意localhost作为域时设置Securetrue会导致Cookie无法被设置因为localhost不是HTTPS。同时在本地开发时前后端端口不同属于“跨站”SameSite如果设为Lax或StrictCookie可能不会随API请求发送通常需要临时设为None并配合Securefalse仅限开发环境。处理Cookie的细节远比想象中多从基础的存取删到复杂的属性设置、安全策略、跨域协同每一步都需要仔细考量。我的经验是在项目初期就确立明确的Cookie使用规范并封装统一的工具函数来强制执行这些规范比如强制设置path/能避免后期大量的调试和重构工作。记住Cookie是Web的基石之一理解它用好它是每一个Web开发者的必修课。
