客户端本地时间错误会导致cookie提前失效，因浏览器完全依赖设备系统时间判断有效期，而非服务器时间；手动调快时间、未开启自动时区同步或长期未校准均会引发此问题，max-age虽比expires更鲁棒但仍受本地时间偏差影响。
客户端本地时间错误会导致 Cookie 提前失效，根本原因在于浏览器判断 Cookie 是否有效时，完全依赖设备自身的系统时间，而不是服务器时间或真实世界时间。
浏览器按本地时间解析过期逻辑
当服务端下发 Set-Cookie: token=abc; Expires=Mon, 26 May 2026 10:00:00 GMT，浏览器会拿这个 GMT 时间和自己系统当前时间做比较。如果用户手机被手动调快了 3 小时，系统时间已是 2026 年 5 月 26 日 13:00，那么该 Expires 时间就被视为“已过去”，浏览器直接拒绝写入——Cookie 甚至没存进去，后续请求自然不携带。
同理，前端用 JavaScript 设置：document.cookie = "x=1; expires=" + new Date(Date.now() + 86400000).toUTCString()
若用户时间比真实时间快 2 小时，实际有效期只剩约 22 小时，而非预期的 24 小时。
HTTPOnly Cookie 同样受本地时间影响
即使 Cookie 是后端通过 Set-Cookie 响应头设置的、且标记为 HttpOnly，其 Expires 字段仍由浏览器本地时间判定是否保留。时间错，照样丢——这不是后端漏设，而是浏览器标准行为。
常见诱因包括：
- 用户为抢购/刷票手动调快手机时间
- 设备未开启自动时区同步（如拉美、东南亚部分低端安卓机）
- 系统时间长期未校准，偏差达数小时甚至几天
max-age 相对更鲁棒，但仍有局限
Max-Age 使用秒数（相对时间），浏览器内部用当前时间 + 秒数算出绝对过期点，因此比 Expires 对格式和时区更不敏感。但它依然依赖本地时间作为起点——若用户时间快 5 小时，max-age=3600 实际只剩 3100 秒左右。
所以：
- Expires 容易因字符串解析、GMT 转换、本地时区误判而失效
- Max-Age 更稳定，但无法绕过“起点不准”这个根本问题
服务端无法干预，只能识别与兜底
前端无法强制修正用户设备时间，但可以：
- 登录后比对服务器返回的时间戳与 Date.now()，差值超 ±300 秒即标记为高风险
- 对高风险用户，避免设长时效 Expires，改用较短 max-age（如 300 秒）并配合后端高频刷新
- 敏感操作要求额外带服务端签名校验的时间戳参数，由后端验证是否在合理窗口内（如 ±90 秒）
