如何在Chrome中为单个网站自定义Cookie过期时间？

功能定位：为什么需要“单站 Cookie 过期时间”

在默认策略里，Chrome 完全信任服务器返回的 Set-Cookie: Max-Age 或 Expires，本地无法直接“缩短”或“延长”某一域名的所有 Cookie。实际业务中，测试环境想模拟会话超时、合规审计要求敏感系统 30 分钟强制失效、或者本地调试需要“永不过期”的登录态，都会遇到“单站粒度”需求。Chrome 132 并未提供官方 UI 开关，但借助三层手段——DevTools 改写、本地脚本覆写、扩展注入响应头——可在“开发机”层面实现目标，而不影响其他站点。

经验性观察：当同一域名下存在多个业务系统共用 Cookie 前缀时，手动调整过期时间能快速验证“统一登出”逻辑，避免反复修改后端配置再部署的等待成本。

前置约束与版本差异

1. 桌面端 Chrome 132 的 DevTools 与 chrome.debugging API 与 Android 版能力不对等；移动端仅能在远程调试模式下使用 DevTools，扩展方案无效。
2. Manifest V3 禁止后台常驻 DOM，因此“拦截响应头”必须采用 declarativeNetRequest with regexFilter，无法像 MV2 那样直接改 header。
3. 所有本地修改只对当前设备生效，清空缓存或换机即失效；若需团队同步，应改用服务器端缩短 Max-Age 或引入 Refresh Token 机制。

补充说明：Chrome 132 的 Site Isolation 默认开启，导致跨子域 Cookie 的内存隔离更严格，脚本拦截时机略有延迟，需把 @run-at 设为 document-start 以提前注入。

方案一：DevTools 手动改写——最快验证

操作路径（桌面端）

1. 打开目标站点，按 F12 → Application → Cookies → 左侧选中域名。
2. 双击任意 Cookie 的 Expires / Max-Age 列，输入新的 UTC 时间或秒数，回车即写回内存。
3. 刷新页面，Network 面板检查后续请求是否携带被改写的 Cookie；如服务器刷新 Set-Cookie，本地值会被覆盖，需要再次改写。

适用场景：一次性调试、临时演示、QA 快速回归。局限：重启浏览器后失效；无法批量改写同名 Cookie（如子域共享）。

小技巧：若需批量调整，可在 Console 执行 document.cookie.split('; ').forEach(c => console.log(c)) 快速列出当前键值，再复制到文本编辑器中统一修改后一次性回写。

方案二：本地覆写脚本——开发机常驻

原理

利用 document.cookie 可写特性，在页面加载后强制重写目标键的过期时间。可封装成油猴脚本（Tampermonkey MV3 兼容版）或本地插件内容脚本。

最小可运行示例

// ==UserScript==
// @name         Cookie-30m
// @match        https://internal.example.com/*
// @grant        none
// @run-at       document-start
// ==/UserScript==

(function(){
  const maxAge = 30 * 60; // 1800 秒
  Object.defineProperty(document, 'cookie', {
    set: function(val) {
      if (val.includes('SessionToken')) {
        val = val.replace(/(;\s*expires=[^;]+|;\s*max-age=[^;]+)/ig, '')
                 + '; Max-Age=' + maxAge;
      }
      this._cookie = val;
    },
    get: function() { return this._cookie || ''; }
  });
})();

经验性观察：在 Chrome 132 的 Site Isolation 下，内容脚本注入时机略早于 document.cookie 被页面代码执行，因此可拦截 90% 以上同域写入。若站点在 Service Worker 里通过 self.cookieStore 写入，则无法拦截。

进阶提示：如果业务同时依赖 HttpOnly Cookie，脚本无法读取原始值，此时可改用扩展方案三，在网络层统一替换，避免前后端不一致导致的 401 异常。

方案三：Manifest V3 扩展——拦截响应头

步骤概览

1. 新建 MV3 扩展，声明 declarativeNetRequest 权限与 host 权限 *://target.site/*。
2. 在 rules.json 中插入 regexFilter，匹配 Set-Cookie 响应头，利用 responseHeaders 修改规则把 Max-Age 替换为目标秒数。
3. 加载扩展后，所有经过网络栈的响应都会被改写，DevTools Network 面板可见 Response Headers 已更新。

警告：declarativeNetRequest 最多支持 30 条动态规则与 5000 条静态规则；若站点通过 JS 后续再次 document.cookie = ...，扩展无法二次拦截，需要配合内容脚本兜底。

经验性观察：在规则数量逼近上限时，Chrome 132 的扩展后台页会抛出 RuleLimitExceeded 异常，可通过 chrome.declarativeNetRequest.getDynamicRules() 定期清理过期规则，避免累积。

平台差异与远程调试提示

Android 132 版：打开 chrome://flags/#enable-usb-debugging → 启用 → 通过 ADB 端口转发 adb forward tcp:9222 localabstract:chrome_devtools_remote，然后在桌面地址栏输入 chrome://inspect 即可看到远程 DevTools。但移动端无法加载未上架扩展，因此方案三不可用；如需批量改写，只能在 Wi-Fi 代理层（如 mitmproxy）插入响应头。

补充：若使用 Android 13 及以上系统，需额外在“无线调试”中允许 ADB 授权，否则 chrome://inspect 列表为空。

常见分支与回退方案

• 若站点启用 Strict Secure Cookie 且本地测试环境为 HTTP，浏览器会拒绝写入；此时需改 hosts 指向 127.0.0.1 并配自签证书，用 HTTPS 访问。
• 当服务器返回 SameSite=None 且未标记 Secure，Chrome 132 会直接拦截，扩展与脚本均无法强制注入；只能让后端修正。
• 如果出现“无限登录”循环，优先检查脚本是否把过期时间写成 0，导致 Cookie 立即被清除；回退办法是临时停用扩展或在 chrome://extensions 关闭“启用”开关。

示例：在本地测试 SSO 系统时，因脚本误将 Max-Age=0 写错成 Max-Age=O（字母 O），导致 Cookie 被立刻删除，登录态无法保持。通过 Network 面板发现 302 循环后，回退到 DevTools 手动改写即可恢复。

验证与观测方法

1. 内存观测：DevTools Application → Cookies 查看 Expires 列是否按预期变化；若使用扩展，可在 Network 面板筛选 set-cookie，确认响应头已改写。
2. 时间漂移测试：将系统时间拨快 29 分钟（假设脚本设定 30 分钟），刷新页面后如被要求重新登录，证明改写生效。
3. 性能基准：空脚本与注入脚本对比，使用 Chrome 132 Performance 录制，脚本执行耗时 < 0.5 ms，对首次渲染无可见影响。

额外建议：在 CI 中可集成 puppeteer 自动拨快系统时间并断言登录态失效，实现回归测试闭环。

不适用场景清单

场景	原因
生产环境面向终端用户	本地修改无法下发给访客，需后端调整 Max-Age
子域数量 > 50 且动态新增	MV3 规则上限 5000，维护成本高
需符合 PCI-DSS 审计	客户端干预不被认可，必须服务器端强制 15 分钟滑动过期
站点使用 CookieStore API	脚本无法拦截 Service Worker 写入

最佳实践决策表

未来趋势与版本预期

Google 在 2026-Q3 将全面下线第三方 Cookie，但第一方 Cookie 的 Max-Age 控制并未在 Privacy Sandbox 路线图中提及。经验性观察，Chromium 团队 Gerrit 近期出现“CookieOverrideUI”实验 flag，可能在未来版本为开发者提供可视化过期调整面板，目前仅停留在代码评审阶段，默认禁用。建议持续关注 chrome://flags/#cookie-overrides 的可用性。

结论

Chrome 132 并未开放“单站 Cookie 过期时间”的官方 UI，但借助 DevTools、本地脚本与 Manifest V3 扩展，可在开发环境中实现“写入即改写”的干预效果。三种方案逐层递进：手动适合临时验证，脚本适合开发机常驻，扩展适合网络层统一拦截。需要牢记的是，本地修改仅限当前设备，无法替代服务器端策略；面对合规审计或大规模用户场景，仍应回归后端缩短 Max-Age 与 Token 轮换机制，才能从根本上满足安全与合规要求。

常见问题

DevTools 改写后的 Cookie 重启浏览器会消失吗？

是的，DevTools 仅修改内存中的 Cookie，未落盘到本地 SQLite，重启后即恢复服务器原值。

MV3 扩展能否拦截 localhost 请求？

可以，但需在 host_permissions 中显式声明 http://localhost:*/*，并勾选“允许访问文件网址”。

脚本拦截失败最常见原因是什么？

站点在 Service Worker 内使用 CookieStore API 写入，脚本无法拦截；需改用扩展在网络层替换。

移动端能否用 MV3 扩展？

Android Chrome 132 不支持未上架扩展，只能借助远程 DevTools 或代理层改写响应头。

时间漂移测试会影响系统其他应用吗？

会，修改系统时间可能导致 TLS 证书验证失败，建议测试完成后立即恢复自动同步。