遇到 Flask session 过期时间的问题，我通常会先确认 session 的存储方式和当前配置。因为很多情况下，开发者以为 session 失效是代码逻辑问题，其实只是默认行为没理解透。

先确认现象：关闭浏览器后 session 还在吗？

Flask session默认使用客户端cookie存储，其生命周期遵循会话cookie规则：当用户关闭浏览器时，session即失效。换句话说，默认情况下session没有固定的过期时间戳，而是与浏览器会话绑定。若希望session跨浏览器会话保留，需将session.permanent属性设为True，此时Flask会依据配置项PERMANENT_SESSION_LIFETIME（默认值为31天）来决定过期时间。
这是最常见的行为。如果你发现用户每次重启浏览器都需要重新登录，而业务上要求记住登录状态几天，那就是因为 session 默认是临时的。此时第一步就是检查代码中是否有设置 session.permanent = True。

容易误判的地方：配置了过期时间却没生效

一个容易踩的坑是：仅设置了PERMANENT_SESSION_LIFETIME却忘记将session.permanent设为True，导致session依然是临时的，关闭浏览器后失效。另一个误区是混淆了session过期时间和cookie过期时间——Flask在设置永久session时虽会添加Cookie的Expires字段，但该字段值由PERMANENT_SESSION_LIFETIME计算得来；若直接手动修改响应Cookie的Max-Age，可能被框架覆盖，导致预期行为不一致。
我之前排查过一个案例：开发在配置里写了 app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(days=7)，但登录视图里没有加 session.permanent = True。结果测试时发现关闭浏览器再打开，session 依然消失。后来补上那一行，问题解决。所以，关键动作是两者缺一不可。

建议的处理顺序：从配置到视图再到验证

自定义session过期时间主要通过修改Flask配置实现。在创建Flask应用后，设置app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(hours=2)即可将永久session的存活期改为2小时。同时务必在登录等关键操作中将session.permanent赋值为True，否则该配置不会生效。若需个别session拥有不同过期时间，可在处理请求时单独设置session.permanent及通过session.modified=True触发写入。
我的处理顺序是：
1. 先在配置文件或 app 创建后设置 PERMANENT_SESSION_LIFETIME，用 timedelta 对象，单位建议用小时或天。
2. 在登录成功的视图函数中，设置 session.permanent = True。
3. 如果需要对特定用户或特定操作使用不同过期时间，可以在那之前修改 session.permanent 并设置 session.modified = True，确保 Flask 重新计算 cookie 过期时间。
4. 立即验证：重启应用，登录后查看浏览器开发者工具中 Set-Cookie 的 Expires 字段是否如预期。

配置示例与验证方法

from datetime import timedelta
app.config['PERMANENT_SESSION_LIFETIME'] = timedelta(days=3)

@app.route('/login', methods=['POST'])
def login():
    # 验证用户逻辑...
    session['user_id'] = user.id
    session.permanent = True  # 使 session 成为永久
    return 'logged in'

若想确认当前session的过期策略，可在开发环境中临时打印session对象的属性。例如在视图函数中输出session.permanent的值，以及通过flask.current_app.permanent_session_lifetime查看当前应用的配置到期时长。更直观的方法是使用浏览器开发者工具查看响应头Set-Cookie中的Expires字段：若session永久，会有一个具体日期时间；若为会话session，则无该字段或值为Session。
注意：Flask 默认使用 secure cookie 签名，所以直接修改 cookie 内容会被拒绝。验证时只关注 Expires 字段即可，不需要解密。

后续维护与回滚边界

修改 session 过期时间属于配置变更，风险较低。但如果生产环境已经在运行，且原有 session 是会话级别的，改为永久后，已登录用户不会受影响（因为他们下次请求时 session 已经存在，但 cookie 会获得新的过期时间）。如果需要回滚，只需改回配置并确保 session.permanent 不再设为 True，然后重启应用。已发出的永久 cookie 会在客户端继续存在直到过期，但服务端不会再为后续请求续期——可以理解为“软回滚”，不影响新登录用户。
如果担心局部 session 过期策略被误覆盖，可以在视图函数中加判断：只有当特定条件满足时才设置 session.permanent = True，否则保持 False。这样避免全站统一永久 session 导致安全风险。例如管理后台可用永久，普通前台用户用会话session。

关于安全边界的一点提醒

session 过期时间越长，被窃取后危害越大。生产环境中建议根据业务敏感度设置合理时长，比如 2 小时或 24 小时，而不是直接使用默认 31 天。如果用户有“记住我”功能，可以结合持久化存储加 token 方式，而 session 本身保持较短过期时间。这样既能提升体验，又能降低风险。