Cookie无法真正设为“无限长”，因浏览器不支持永久语义，仅能设极远时间（如9999年或Max-Age=2147483647），但存在兼容性、系统时间限制、手动清理及服务端主动过期等问题，且违反隐私法规与安全最佳实践。
Cookie 有效期不能真正设置为“无限长”，根本原因在于技术实现和安全设计的双重限制，而不是单纯因为开发者没想出来怎么写。
浏览器不支持真正的“永不过期”
所有主流浏览器都不提供“永久保存”的语义支持。所谓“永不过期”，实际只是把过期时间设得极远——比如设为公元9999年，或用 Max-Age=2147483647（32位有符号整数最大值，约68年）。但这种做法存在明显问题：
- 部分老旧浏览器或嵌入式环境可能无法正确解析超大数值，导致行为异常（如直接忽略 Max-Age）
- Expires 时间若超出浏览器内部时间表示范围（例如某些系统仅支持到2038年），会被截断或转为会话 Cookie
- 用户手动清理数据、重装系统、更换设备时，“长期有效”立即失效
服务端通常不信任客户端的长期凭证
即使浏览器保留了 Cookie，服务端一般也会主动限制其实际效力：
- 后端常配合 Redis 或数据库存储 session 状态，并设置独立的过期策略（如 7 天无操作即销毁）
- 敏感操作（如修改密码、支付）会强制重新验证身份，不依赖 Cookie 是否“还在”
- Token 类机制（如 JWT）普遍自带签发时间（iat）和过期时间（exp），服务端校验时以自身时间为基准，不受客户端篡改影响
隐私与合规要求倒逼时效收紧
GDPR、CCPA 等法规明确要求：用户数据存储必须具备合理期限，且需提供便捷的撤回机制。将 Cookie 设为“几十年后才过期”，本质上违背了“数据最小化”和“目的限定”原则：
- 浏览器厂商已在逐步限制长期 Cookie 的默认行为（如 Safari 的 ITP、Chrome 的第三方 Cookie 限制）
- 许多网站在用户长时间未登录后，会主动使旧 Cookie 失效，避免账号被盗用风险
- 审计或安全扫描工具会将超长 Max-Age（如 >365 天）标记为高风险配置
替代方案更可靠也更常用
真要实现“长期登录体验”，行业通用做法不是靠 Cookie 撑时间，而是组合使用：
- 主 Cookie 设为较短有效期（如 7 天），搭配一个加密的 Refresh Token 存于 HttpOnly Cookie 中
- 用户访问时用 Refresh Token 向服务端换新凭证，既保持体验又控制风险
- 关键操作前仍需二次验证（短信、邮箱、生物识别等）
