生产环境必须关闭 Flask 调试模式、禁用硬编码 SECRET_KEY、启用安全 Cookie 选项、确保 CSRF 保护生效，并校验部署配置协同性。
检查 DEBUG 是否为 False 在生产环境
线上跑着 DEBUG=True 的 Flask 应用，等于把调试器和完整错误堆栈直接暴露给任意请求者——攻击者能直接看到路径、环境变量、数据库连接串甚至源码片段。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 部署前必须确认
app.config['DEBUG']是False，且不能靠os.environ.get('FLASK_DEBUG')动态覆盖（环境变量容易被误设） - 更稳妥的做法是显式写死：
app.config['DEBUG'] = False，并在启动时加校验逻辑，比如assert not app.debug, "DEBUG must be False in production" - 注意：
flask run --debug命令会强制开启调试模式，生产环境禁止用该命令启动
禁用 SECRET_KEY 硬编码与空值
SECRET_KEY 是 session 加密、CSRF token 签名等安全机制的根基。空值、固定字符串（如 "devkey"）、Git 提交进仓库，都会导致 session 被伪造或 CSRF 防御失效。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 绝不能写
app.config['SECRET_KEY'] = 'my-secret'这类硬编码；应从环境变量读取：os.environ.get('SECRET_KEY') - 启动时必须校验非空：
if not app.secret_key: raise ValueError("SECRET_KEY is not set") - 生成强密钥可用：
secrets.token_urlsafe(32)，别用random模块 - 若用 Docker，确保
SECRET_KEY通过--env-file或docker-compose.yml的environment注入，不写进镜像层
关闭 SESSION_COOKIE_SECURE 和 SESSION_COOKIE_HTTPONLY 的默认陷阱
Flask 默认不设 SESSION_COOKIE_SECURE，意味着 cookie 会在 HTTP 明文传输中被截获；SESSION_COOKIE_HTTPONLY 若为 False（默认值），JS 可读取 session cookie，增加 XSS 后窃取风险。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
立即学习“Python免费学习笔记（深入）”；
- HTTPS 环境下必须设：
app.config['SESSION_COOKIE_SECURE'] = True - 始终启用：
app.config['SESSION_COOKIE_HTTPONLY'] = True（这是防御 XSS 的基础线） - 考虑加上：
app.config['SESSION_COOKIE_SAMESITE'] = 'Lax'，缓解 CSRF（但不能替代 CSRF token） - 注意：本地开发若没配 HTTPS，
SESSION_COOKIE_SECURE=True会导致 cookie 不发送——可按环境区分配置，但切勿在生产配置里留False
验证 WTF_CSRF_ENABLED 是否开启并配对前端
Flask-WTF 默认开启 CSRF 保护，但很多人只加了 CSRFProtect(app) 却忘了在表单里渲染 {{ form.csrf_token }}，或前端用 AJAX 提交时没带 header，结果保护形同虚设。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 确认已启用：
app.config['WTF_CSRF_ENABLED'] = True（0.15+ 版本默认为True，但显式声明更稳妥） - 模板中每个 POST 表单必须包含：
{{ form.hidden_tag() }}或手动写{{ form.csrf_token }} - AJAX 请求需在 header 中带上：
X-CSRFToken: {{ csrf_token() }}，后端用@csrf.exempt仅豁免真正无需防护的接口（如公开健康检查） - 别关掉它来“解决跨域问题”——跨域和 CSRF 是两回事，关 CSRF 只会让应用裸奔
真正难的不是记住这些配置项，而是每次部署都得重新核对环境变量、启动方式、反向代理设置是否协同生效。比如 Nginx 没转发 X-Forwarded-Proto，SESSION_COOKIE_SECURE 就会失效；又比如用 Gunicorn 启动却忘了传 --preload，导致配置在 worker 间不一致。这些点不在代码里，但在上线那一刻才暴雷。
