最稳妥方式是用Config类继承管理不同环境配置，基类放默认值，子类覆盖关键项，通过app.config.from_object()传入已导入的类对象，并在create_app()中按环境变量加载，敏感配置须从环境变量读取且避免类属性直接调用os.environ。
Flask 里怎么用 Config 类管理不同环境配置
直接用类继承是最稳妥的方式，不是靠改文件名或手动改变量。Flask 本身不强制要求某种结构，但通过 Config 类能清晰隔离 Dev/Prod 差异，也方便测试和部署时注入。
常见错误是把所有配置写进一个 config.py 里，用 if os.getenv('FLASK_ENV') == 'production' 切换——这会导致启动时加载全部配置，敏感信息可能提前暴露，且无法被 IDE 或 linter 有效检查。
-
Config基类只放通用、无敏感信息的默认值（如JSON_SORT_KEYS = False） -
DevelopmentConfig和ProductionConfig分别继承它，覆盖关键项：数据库 URL、密钥、调试开关 - 生产环境必须禁用
DEBUG = False，否则会暴露堆栈和交互式调试器 - 密钥不能硬编码在代码里，应通过
os.getenv('SECRET_KEY')读取，本地开发可用.env文件配合python-dotenv
app.config.from_object() 怎么选对配置类
调用这个方法时传入的是类对象，不是字符串。很多人写成 from_object('config.DevelopmentConfig')，结果报 ImportError: No module named 'config' 或静默失败——因为 Flask 不做字符串导入，只认已导入的类引用。
典型使用场景是 create_app() 工厂函数中根据环境变量决定加载哪个类：
def create_app():
app = Flask(__name__)
env = os.getenv('FLASK_ENV', 'development')
if env == 'production':
app.config.from_object('config.ProductionConfig')
else:
app.config.from_object('config.DevelopmentConfig')
return app
- 确保
config.py在 Python path 中（通常放在项目根目录或app/下） - 更推荐方式是先
import config，再传config.DevelopmentConfig——避免字符串解析风险 - 如果用 Gunicorn 启动，
FLASK_ENV不生效，应改用FLASK_CONFIG并在入口脚本里解析
数据库 URL、密钥这些敏感配置为什么不能写死在 config.py
写死就等于把密码提交进 Git，哪怕加了 .gitignore，新人 clone 后一运行就报错，或者误用本地密钥连上生产 DB。这不是“小心点就能避免”的问题，而是架构层面的设计漏洞。
-
SQLALCHEMY_DATABASE_URI必须从环境变量读取：os.getenv('DATABASE_URL', 'sqlite:///dev.db') -
SECRET_KEY同理，生产环境务必设为 24 字符以上随机字符串，不能用'devkey'这类占位符 - 开发环境可依赖
python-dotenv自动加载.env，但该文件必须在.gitignore中，且不能出现在任何构建镜像里 - 某些云平台（如 Heroku、Render）会自动注入环境变量，这时
.env完全不需要存在
为什么 Config 类里不能用 os.environ.get() 直接赋值给类属性
因为类定义时就会执行，而此时环境变量可能还没加载完（尤其用 dotenv.load_dotenv() 时）。结果就是 SECRET_KEY 是 None，启动时报 RuntimeError: A secret key is required to use CSRF。
- 所有依赖环境变量的配置，必须在实例化后、
app.config.from_object()调用之后才读取 - 正确做法是在类里留空或设默认值，然后在
create_app()里用app.config['SECRET_KEY'] = os.getenv('SECRET_KEY')补充 - 或者改用工厂函数返回配置实例：
app.config.from_object(config.DevelopmentConfig())，让__init__控制读取时机 - 注意：
Config类不能有__init__，但子类可以有，Flask 支持传入实例
