必须配置 SECRET_KEY，否则 session 操作会抛出 RuntimeError: The session is unavailable；它需为非空、强随机字符串，优先用 secrets.token_hex(16) 生成，并通过环境变量安全注入。
不配 SECRET_KEY 就会 runtimeerror: The session is unavailable
Flask 的 session 默认走客户端 cookie，所有数据都用 SECRET_KEY 签名加密后存进浏览器。没设它，Flask 启动时不报错，但一执行 session['user_id'] = 123 或 session.get('user_id')，立刻抛出 RuntimeError: The session is unavailable because no secret key was set。
常见假象是“赋值成功了”，其实只是字典操作没崩，但响应里根本没写新 cookie；下次请求时 cookie 解不了签，session 就是空的——查日志也看不到明显线索，容易卡半天。
-
SECRET_KEY必须是字符串，不能是bytes（比如直接用os.urandom(24)赋值会失败） - 不能是空字符串、
'dev-key'或其他弱值；Flask 2.3+ 会直接拒绝启动 - 多实例部署时，所有进程必须用同一个
SECRET_KEY，否则用户刷新就登出
生成 SECRET_KEY：优先用 secrets.token_hex(16)
secrets 模块专为密码学安全设计，比 random 和裸 os.urandom 更可靠。生成命令一行搞定：
python -c "import secrets; print(secrets.token_hex(16))"
输出类似 3a7d4e1f8c45b96d1024a67e5f8d9c0b，长度 32 字符（对应 16 字节），够用且兼容性好。
立即学习“Python免费学习笔记（深入）”；
- 别用
random.choice拼字符串——它不是加密安全的 - 避免
os.urandom(24).hex()直接塞进代码：虽然安全，但每次重启变一次，开发调试没问题，上线就炸 - 长度别瞎加：小于 16 字节（32 hex）有被暴力风险；大于 32 字节纯属冗余
配置 SECRET_KEY：必须从环境变量读，不能硬编码
硬编码在 app.py 或 config.py 里等于把钥匙贴在门上。正确姿势是环境变量 + fallback：
import os
from flask import Flask
app = Flask(__name__)
app.config['SECRET_KEY'] = os.environ.get('FLASK_SECRET_KEY')
然后通过以下任一方式注入：
- 开发：用
python-dotenv加载.env文件，内容为FLASK_SECRET_KEY=3a7d4e1f8c45b96d1024a67e5f8d9c0b - 生产：Linux 下运行
export FLASK_SECRET_KEY='xxx'，或容器中用environment:配置 - 绝对不要在 Git 提交里出现
SECRET_KEY字样，连注释都不行
session 写入失效？检查 SECRET_KEY 是否一致且已生效
即使配了 SECRET_KEY，也可能因以下原因导致 session 看似不工作：
- 用了
app.secret_key = ...但漏掉app.config['SECRET_KEY']——两者等价，但某些扩展只认后者 - 在
Flask(__name__)之后才设置，部分中间件（如某些 WSGI 封装）可能已初始化 session 接口 - 本地开发时改了
.env却没重启服务，旧进程还在用老密钥 - 用
flask run启动但没加载.env（需确认是否安装python-dotenv）
最稳的验证方式：启动后立即打印 app.config.get('SECRET_KEY')，确保不是 None，且长度和格式符合预期。密钥问题往往藏得深，但只要它不对，session 就一定不可靠。
