SECRET_KEY必须固定，否则session签名失效导致用户登出；需从环境变量读取≥32字节密钥，未设置时session看似可用实则无效，嵌套修改需整体赋值且仅支持JSON安全类型。
SECRET_KEY 不固定，session cookie 签名直接失效
Flask session 默认走 SecureCookieSessionInterface，所有数据序列化后存进浏览器 Cookie，并用 SECRET_KEY 生成 HMAC-SHA256 签名。这不是加密，是防篡改——但签名密钥一变，旧 Cookie 就无法验证。
常见错误现象：
- 本地用
os.urandom(24)每次启动都生成新密钥，登录后刷新或重启服务，session.get('user_id')突然返回None - 使用
flask run --reload时，热重载触发密钥重生成，已登录用户全部“被登出” - 部署到 Gunicorn/Uvicorn 多 worker 时，每个进程用不同密钥，用户请求落到不同 worker 就频繁掉登录态
正确做法：
-
app.config['SECRET_KEY']必须是固定字符串，不能在每次app = Flask(__name__)时动态生成 - 开发阶段可用硬编码（如
'dev-secret-32-bytes-xxxxxxxxxxxxxxxxxxxxxxxx'），但上线必须从环境变量读：os.environ.get('SECRET_KEY') - 密钥长度建议 ≥32 字节；避免用
'dev-key'、'123'这类弱值，Flask 会拒绝空或过短的密钥
没设 SECRET_KEY 时 session 看似能写，实则根本没生效
不配 SECRET_KEY，Flask 启动不报错，但第一次读写 session 就抛 RuntimeError: The session is unavailable because no secret key was set。更隐蔽的是：某些调试模式下（如 debug=True）可能静默 fallback 到内存字典，造成“能存能取”的假象。
立即学习“Python免费学习笔记（深入）”；
这导致的问题：
- 本地测试一切正常，部署后全员登出，查日志却看不到明显报错
-
session['user_id'] = 123执行无异常，但下个请求里session.get('user_id')是None，因为没密钥就无法签发有效 Cookie
验证方法：打开浏览器开发者工具 → Application → Cookies，检查是否有 session 条目；没有，说明密钥缺失或配置未生效。
session.permanent = True 不解决重启失效问题
设 session.permanent = True 只影响 Cookie 的 Expires 时间（默认 31 天），和密钥无关。它不能让 session 在服务重启后“复活”，因为 session 数据本身不在服务端持久化——Flask 默认不存数据库、不连 Redis，全靠客户端 Cookie + 服务端密钥验证。
所以：
- 即使设置了
permanent，只要SECRET_KEY变了，旧 Cookie 仍被丢弃 - 想真正持久化 session，得换后端存储（如
Flask-Session+ Redis），但这不是默认行为，也不解决密钥配置错误这个前提问题 -
session.permanent必须在赋值前设置，写成session['x'] = 1; session.permanent = True是无效的
嵌套字典修改不触发 session 写入
session 表面像字典，但底层是带状态跟踪的 SecureCookieSession。直接改嵌套结构不会标记为“已修改”，响应头里就不会更新 Cookie。
例如：
session['data'] = {'items': [1, 2]}
session['data']['items'].append(3) # ❌ 这行不触发写入
# 下次请求中 session['data'] 还是 {'items': [1, 2]}
正确写法：
- 先取出来，改完再整体赋值：
data = session.get('data', {}); data['items'].append(3); session['data'] = data - 值必须是 JSON 安全类型（
str/int/list/dict/None/bool），不能塞datetime、自定义 class 或函数对象
这个坑常和密钥问题叠加：你以为 session 没失效，其实是数据根本没存进去。
