Actix-web 不直接管理 Cookie 有效期，而是通过 cookie crate 设置 max-age（推荐，秒数计算）、expires（GMT 时间字符串，易受时钟偏差影响）、secure（仅 HTTPS）、SameSite 和 Path 等字段；session 中间件默认自动刷新 TTL 30 分钟。
Actix-web 本身不直接管理 Cookie 有效期，它依赖底层 HTTP 协议规范和 Rust 的 cookie 库（如 cookie crate）来构造符合标准的 Set-Cookie 响应头。所谓“配置不同”，本质是开发者在调用过程中对 max-age、expires、secure、http_only 等字段的组合方式不同，而这些字段的行为由浏览器严格执行，并非框架“自定义逻辑”。
max-age 和 expires 不能共存，且语义完全不同
两者都控制过期，但机制相反：
-
max-age（推荐）：传入一个正整数秒数（如
3600），浏览器用本地当前时间 + 该值计算绝对过期点。它不依赖系统时钟精度，抗时间偏差能力更强；设为0表示立即删除，设为负数（如-1）等效于不设置，退化为会话 Cookie。 -
expires：必须是严格格式的 GMT 时间字符串（如
"Wed, 21 Oct 2026 07:28:00 GMT"）。一旦客户端系统时间比该值早，Cookie 直接被忽略——跨国用户调快手机时间抢购、设备未同步 NTP，都会导致“设了等于没设”。
secure 属性强制要求 HTTPS 连接
如果代码中启用了 secure = true（例如通过 Cookie::build().secure(true)），但当前请求走的是 http://localhost:8080，浏览器会直接丢弃该 Set-Cookie 头，并在控制台报错：“This attempt to set a cookie was blocked because it had the Secure attribute but was not received over a secure connection”。开发时容易忽略这点，尤其在本地测试阶段。
SameSite 和 Path 配置影响实际生效范围
即使有效期设置正确，Cookie 也可能“存在却不可见”：
-
Path：若设为
/admin，则只有/admin/xxx路径下的请求才携带该 Cookie；根路径应显式写set_path("/")，不能留空或写"."。 -
SameSite：默认值在现代浏览器中已是
Lax。若前端发起跨站 POST 请求（如从https://a.com提交表单到https://b.com），而 Cookie 设了SameSite=Strict，则不会附带——看起来像“失效”，实则是被策略拦截。
Session 中间件自动管理生命周期，掩盖底层细节
使用 actix-session 时，框架会自动处理加密、签名、存储与过期。它的默认 TTL（time-to-live）是 30 分钟，且每次请求都会刷新。此时你看到的 Cookie 可能始终是“刚设置的”，并非因为有效期配错了，而是中间件在后台持续续期。若想禁用自动刷新，需手动配置 SessionBackend::cookie_lifespan() 并关闭 session_ttl_on_refresh。
