必须配置SECRET_KEY，否则Flask session操作会抛出RuntimeError；需设为固定强随机字符串（如secrets.token_hex(16)），通过环境变量注入，且必须在Session(app)之前完成设置。
Flask-Session 初始化失败：RuntimeError: session is unavailable because no secret key was set
这个报错和 Redis 完全无关，是 Flask 底层校验拦下来的。即使你只配了 SESSION_TYPE='redis'，Flask-Session 仍依赖 SECRET_KEY（或 app.secret_key）对 session ID 做签名。漏设、设成 os.urandom(24) 这类动态值，或者设在 Session(app) 之后，都会触发该错误。
必须确保：
-
app.config['SECRET_KEY']是固定字符串（如从环境变量读取），禁止运行时生成 - 设置顺序在
Session(app)之前 - 所有部署实例用同一份
SECRET_KEY
Redis 连接配置常见陷阱：decode_responses=True 导致序列化失败
flask-session 内部使用 pickle（默认）或 json 序列化 session 数据，写入 Redis 时是二进制字节流。若你手动创建 redis.Redis(..., decode_responses=True)，Redis 客户端会把所有返回值强制转为字符串，导致 flask-session 读取时解码失败，出现 BadPickleGet 或静默丢数据。
正确做法：
-
SESSION_REDIS必须用decode_responses=False（默认值，可不显式写） - 不要复用业务用的、带
decode_responses=True的 Redis 实例 - 推荐用连接池：
redis.ConnectionPool(host='localhost', port=6379, max_connections=20)，再传给redis.Redis(connection_pool=pool)
Session 数据读不到：key_prefix、TTL 和 itsdangerous 版本不一致
多个 Flask 实例连同一个 Redis，但部分实例读不到 session，大概率是以下三者之一：
-
SESSION_KEY_PREFIX不统一（比如一个设'myapp:'，另一个没设，默认是'session:'） -
PERMANENT_SESSION_LIFETIME值不同，导致某些实例认为 session 已过期而拒绝读取 - 不同机器上
itsdangerous版本不一致（如 2.0.1 vs 2.1.2），签名格式微调，旧 session 解不出
调试时直查 Redis：redis-cli KEYS "flask_session:*" 看 key 是否存在；GET "flask_session:xxx" 看值是否为合法 JSON（若启用了 SESSION_SERIALIZER=json）；TTL "flask_session:xxx" 看剩余时间是否符合预期。
生产环境必须禁用 pickle，改用 json 序列化
flask-session 默认用 pickle 存 session，但 pickle 反序列化有远程代码执行风险。只要攻击者能控制 Redis 数据（如未授权访问、注入漏洞），就能触发任意命令执行。
安全做法是强制切换为 json：
- 加配置：
app.config['SESSION_SERIALIZER'] = json（注意不是字符串'json'） - 同时确保 session 中只存 JSON 原生类型（
str、int、float、bool、None、list、dict） - 遇到
datetime、Decimal等类型，得提前转成字符串或 ISO 格式
这个点最容易被忽略——配置写了，但业务代码里还往 session 塞 datetime.now()，结果写入静默失败，后续 get 返回 None，问题难定位。
