chrome对cookie有效期设400天硬性上限，源于chromium源码中kmaxcookieagesecs常量限制，自chrome 51起实施，旨在平衡长期登录需求与隐私安全管控。
Chrome 从较早版本起就对 Cookie 的 Max-Age 或 Expires 设置施加了硬性上限，并非仅限于 Chrome 104。你观察到“设置 10 年却只生效约 400 天”，根本原因在于 Chromium 内核中对 Cookie 过期时间的主动截断逻辑，而非浏览器 Bug 或配置错误。
Chrome 对 Cookie 有效期的硬性限制
Chromium 源码中（位于 net/cookies/canonical_cookie.cc）明确将服务端或 JS 设置的过期时间上限限定为 400 天（精确值为 400 * 24 * 3600 秒 = 34,560,000 秒）。只要解析出的过期时间超过该阈值，就会被强制修正为 creation_time + 400 days。
- 这个限制自 Chrome 51 左右引入，持续沿用至今（包括当前最新稳定版），Chrome 104 完全继承该策略
- 无论后端
Set-Cookie: expires=Fri, 31 Dec 2033 23:59:59 GMT写得多远，或前端document.cookie = "a=b; max-age=315360000"设得多大，最终存入 Cookie 数据库的有效期都不会超过 400 天 - 官方未将其列为 bug，而是视为一项安全与存储管理机制：防止因误设超长有效期导致 Cookie 永久滞留、占用磁盘、影响隐私清理逻辑
为什么是 400 天？
这不是随意取的整数，而是权衡结果：
- 足够覆盖绝大多数“长期记住我”场景（如 1–2 年）
- 避免 Cookie 实际“永久化”，保留用户可控的退出与清理路径
- 减少因时钟漂移、跨设备时间不同步引发的异常行为（比如服务器时间比本地快几年，导致 Cookie 瞬间过期）
开发者能绕过吗？
-
普通网页脚本无法绕过：
document.cookie和Set-Cookie均受该限制约束 - 服务端无法单方面突破：浏览器在接收并解析 Cookie 时即完成截断，服务端无感知
-
唯一可行路径是修改 Chromium 源码并自行编译浏览器：定位
ValidateAndAdjustExpiryDate()函数，调整kMaxCookieAgeSecs常量（目前定义为400 * 24 * 3600），但这仅适用于极少数定制化内网环境，不适用于公开分发或日常使用
不复杂但容易忽略
