Flask中session过期由PERMANENT_SESSION_LIFETIME和session.permanent共同控制：仅设前者无效，必须显式设session.permanent=True；PERMANENT_SESSION_LIFETIME须为timedelta对象，且需在写session后或before_request中设置permanent=True。
Session过期时间由PERMANENT_SESSION_LIFETIME和session.permanent共同控制
Flask默认的session是基于客户端cookie的，不设永久性时，关闭浏览器即失效；设为永久后，才真正走PERMANENT_SESSION_LIFETIME配置。很多人只改了PERMANENT_SESSION_LIFETIME却忘了设session.permanent = True，结果过期时间始终无效。
实操建议：
-
app.config['PERMANENT_SESSION_LIFETIME']必须是datetime.timedelta对象，比如timedelta(hours=2)，不能传整数秒或字符串 - 每次写session前（如
session['user_id'] = 123之后），显式调用session.permanent = True，否则该次session仍按浏览器会话生命周期处理 - 若全局统一设永久session，可在
before_request里统一置session.permanent = True，但要注意这会让所有session都受PERMANENT_SESSION_LIFETIME约束
使用Redis或Memcached做服务端session需替换session_interface
Flask默认session序列化后存cookie里，敏感数据不安全，且大小受限（通常SessionInterface。
常见做法是用Flask-Session扩展，它封装了Redis/Memcached/SQLAlchemy等后端：
立即学习“Python免费学习笔记（深入）”；
- 安装：
pip install Flask-Session - 配置Redis后端时，必须设
SESSION_TYPE = 'redis'，并提供SESSION_REDIS（如redis.Redis()实例）或SESSION_REDIS_URL -
SESSION_PERMANENT控制是否启用PERMANENT_SESSION_LIFETIME，而SESSION_USE_SIGNER决定是否签名cookie（防篡改，建议开启） - 注意：
Flask-Session把session ID存在cookie里，真实数据存在Redis中，所以即使用户清cookie，只要Redis里key没过期，重登可能复用旧session（取决于业务逻辑）
session.clear()不会立即删除服务端存储，需配合后端清理机制
调用session.clear()或session.pop('key')只清除当前请求上下文中的session字典，对Redis/Memcached里的原始记录无影响。这是最容易被忽略的“假清除”陷阱。
解决方式取决于后端：
- 用
Flask-Session+ Redis时，可手动触发session_interface.cleanup()（需继承并重写），或更稳妥地：在登出路由里，用session_interface.delete(session.sid)显式删Redis key - 若用自定义
RedisSessionInterface，应在save_session方法里检查session.modified == False and not session，主动调用redis.delete(sid) - 别依赖Redis的
expire自动清理——万一SESSION_PERMANENT=False，Flask-Session默认不设TTL，Redis key会永久残留
开发环境误用SECRET_KEY硬编码导致session频繁失效
Flask session cookie靠SECRET_KEY签名，每次重启服务若SECRET_KEY变，旧cookie就无法解签，表现为“登录后立刻掉session”。开发时写死app.config['SECRET_KEY'] = 'dev-key'看似方便，但热重载、多进程或容器重建都会触发失效。
稳妥做法：
- 生产环境必须从环境变量读取：
app.config['SECRET_KEY'] = os.environ.get('SECRET_KEY')，并确保部署时稳定不变 - 开发时可用
os.urandom(24)生成一次存文件，避免每次启动都变；但切勿提交到Git - 如果用了
Flask-Session且启用了SESSION_USE_SIGNER，它还会额外用SECRET_KEY签名session ID cookie，双重依赖，改错一个就全崩
session的持久化不是开关一开就完事，关键在SECRET_KEY稳定性、服务端存储的清理时机、以及permanent标记的显式设置——三者缺一不可。
