GraphQL无法在响应体中返回Cookie有效期，因Cookie过期由HTTP响应头（如Set-Cookie）控制；服务端需通过响应体字段（如expiresAt）、自定义响应头（如X-Session-Max-Age）或前端推算三种方式向客户端传递该信息。
GraphQL 本身不直接处理 HTTP 响应头（如 Set-Cookie），因此无法在查询响应体（JSON）中“返回”Cookie 的有效期（例如 Expires 或 Max-Age）。但你可以通过以下几种合理方式，让前端获知 Cookie 的有效期信息：
方式一：在 GraphQL 响应中显式返回有效期字段
后端在解析认证/会话状态时，读取当前 Cookie（如 session ID）对应的服务端会话元数据，从中提取过期时间，并作为字段返回给客户端。
- 适合场景：使用服务端会话（如 Redis 存储 session，含
expiresAt字段） - 示例 schema 片段：
type SessionInfo {<br> isLoggedIn: Boolean!<br> expiresAt: String! # ISO 8601 时间字符串，如 "2025-04-10T14:22:30Z"<br> maxAgeSeconds: Int # 可选，便于前端倒计时计算<br>} - Resolver 中需主动查 session 存储，获取其过期时间，而非依赖 HTTP 头
方式二：通过自定义 HTTP 响应头传递（非 GraphQL 响应体）
GraphQL 服务器（如 Apollo Server、Express + graphql-http）仍运行在 HTTP 之上，可在执行 resolver 后手动设置响应头。
- 例如，在登录成功后，除返回 JSON 数据外，同时设置：
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure; Max-Age=3600
并额外添加：X-Session-Expires: 1744294950（Unix 时间戳）或X-Session-Max-Age: 3600 - 前端可在 fetch 响应中读取这些自定义 header（需后端开启 CORS 暴露）：
Access-Control-Expose-Headers: X-Session-Expires, X-Session-Max-Age - 注意：浏览器不会将该 header 用于自动 Cookie 管理，仅作参考；真正控制 Cookie 过期的是
Set-Cookie中的Max-Age或Expires
方式三：由前端自行推算（适用于简单策略）
如果后端采用固定过期策略（如所有会话均为 1 小时），可约定规则，前端根据登录成功时间 + 固定时长自行计算失效点。
- 优点：无需额外传输，减少耦合
- 缺点：缺乏灵活性；若服务端动态调整过期策略（如活动延长、滑动过期），前端无法感知
- 建议搭配方式一或二做兜底校验，避免时钟偏差导致误判
关键提醒
不要尝试在 GraphQL 响应体中伪造 Set-Cookie 头内容 —— 客户端不会解析并应用它；Cookie 的设置权始终在 HTTP 层，由浏览器根据响应头执行。
HttpOnly Cookie 无法被 JavaScript 读取，所以前端无法通过 document.cookie 获取其过期时间；必须由服务端主动提供。
实际落地时，推荐组合使用方式一（响应体带 expiresAt）+ 方式二（响应头带 X-Session-Max-Age），兼顾可读性与精确性。
