Flask 3.0 移除自动加载 .env，须手动调用 load_dotenv() 并在创建 app 前执行；关键配置需显式校验，推荐使用 from_prefixed_env() 按前缀加载环境变量，弃用 FLASK_ENV，生产环境禁用 debug。
Flask 3.0 中 app.config.from_envvar() 不再隐式加载 .env 文件
Flask 3.0 移除了对 python-dotenv 的自动依赖，app.config.from_envvar('CONFIG_FILE') 只会从系统环境变量读取一个文件路径，不会自动查找或加载项目根目录下的 .env。如果你还按老习惯只放 .env、不显式调用 load_dotenv()，所有 os.getenv() 都会返回 None —— 连数据库连不上、密钥拿不到、SECRET_KEY 缺失导致 session 全崩。
必须手动加载：
from flask import Flask
from dotenv import load_dotenv
import os
<h1>必须在创建 app 实例前调用</h1><p>load_dotenv() # 默认加载项目根目录下的 .env</p><p>app = Flask(<strong>name</strong>)
app.config['SECRET_KEY'] = os.getenv('SECRET_KEY')
app.config['SQLALCHEMY_DATABASE_URI'] = os.getenv('DATABASE_URL')</p>
常见错误：把 load_dotenv() 放在 app = Flask(...) 之后，或放在蓝本（Blueprint）里 —— 此时配置已初始化完毕，后续赋值无效。
敏感字段必须做存在性校验，不能只设默认值
os.getenv('DB_PASSWORD', 'default') 看似安全，实则危险：一旦环境变量名拼错（比如写成 DB_PASSWD），应用会静默使用默认值连接数据库，可能连到测试库甚至本地空实例，造成数据误刷。
正确做法是明确区分「可选配置」和「必填敏感项」：
- 对
SECRET_KEY、DB_USER、DB_PASSWORD、DB_HOST这类关键字段，用os.getenv()+ 显式判空 - 避免给密码类字段设任何字符串默认值
- 启动时集中校验，失败立刻抛出
ValueError
示例：
required = ['SECRET_KEY', 'DB_HOST', 'DB_USER', 'DB_PASSWORD', 'DB_NAME']
missing = [k for k in required if not os.getenv(k)]
if missing:
raise ValueError(f"Missing required env vars: {missing}")
from_prefixed_env() 是 Flask 3.0 处理多环境配置的推荐方式
比起零散地写一堆 os.getenv('XXX')，Flask 3.0 内置的 app.config.from_prefixed_env('MYAPP') 更干净——它会自动提取所有以 MYAPP_ 开头的环境变量，并转成大写键名（如 MYAPP_DEBUG → DEBUG），直接注入 app.config。
优势明显：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 无需手动映射，减少拼写错误
- 天然支持 12-factor 风格部署（Docker/K8s 中通过
env:注入即可） - 避免污染全局环境变量空间（只读取带前缀的）
用法：
# 启动前设置：
# export MYAPP_DEBUG=true
# export MYAPP_DATABASE_URI="mysql+pymysql://user:pass@db:3306/prod"
<p>app.config.from_prefixed_env('MYAPP') # 自动加载并转换</p><h1>此时 app.config['DEBUG'] 和 app.config['DATABASE_URI'] 已就绪</h1>
注意：from_prefixed_env() 不会覆盖已存在的 config 键，所以建议在 from_object() 基础配置之后调用，让环境变量优先级更高。
生产环境禁止用 FLASK_ENV，改用 FLASK_DEBUG + 显式 app.run()
Flask 3.0 完全弃用了 FLASK_ENV=production 这个环境变量。它不再控制调试模式，也不影响 Werkzeug 的重载行为。继续用会导致：
-
FLASK_ENV=production被忽略，但debug=True仍可能被意外启用 - Werkzeug 的开发服务器在生产中运行，存在代码重载和调试器暴露风险
正确姿势：
- 永远不要在生产环境设置
FLASK_DEBUG=true - 启动命令统一用
gunicorn或uvicorn，禁用app.run() - 若必须用
app.run()（仅限调试），显式传参：app.run(debug=False)，不依赖环境变量
最稳妥的判断逻辑：
debug_mode = os.getenv('FLASK_DEBUG', 'false').lower() in ('true', '1', 't')
if debug_mode and os.getenv('ENVIRONMENT') != 'development':
raise RuntimeError("FLASK_DEBUG must be false in non-development environments")
真正容易被忽略的是：Flask 3.0 的配置加载顺序不可逆，且 from_prefixed_env() 和 from_object() 的叠加效果取决于调用时机。一旦 config 键被写入，后续同名环境变量不会覆盖——这意味着你得在代码最开头就规划好加载链，而不是边写边补。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
