config.from_object必须传入类对象而非实例，因其内部用getattr读取类属性，实例属性可能未初始化或带副作用；传入实例会导致配置丢失且无报错。
config.from_object 为什么必须传入类对象而不是实例
因为 config.from_object 内部会用 getattr 逐个读取类属性，不支持从实例读取（实例属性可能带副作用或未初始化）。传入实例会导致配置项丢失，且无报错提示。
常见错误写法：app.config.from_object(Config()) —— 看似合理，实际跳过所有配置。
- 正确做法是传入类名：
app.config.from_object(Config) - 类中所有大写命名的属性（如
DEBUG,SQLALCHEMY_DATABASE_URI）才会被加载 - 类可以定义
__init__，但不会被调用；也不应依赖self初始化逻辑
如何组织 Development / Production / Testing 三套配置类
推荐用继承结构，避免重复和遗漏。父类放公共配置，子类覆盖差异项：
class Config:
SECRET_KEY = os.environ.get('SECRET_KEY') or 'dev-key'
SQLALCHEMY_TRACK_MODIFICATIONS = False
class DevelopmentConfig(Config):
DEBUG = True
SQLALCHEMY_DATABASE_URI = os.environ.get('DEV_DATABASE_URL') or \
'sqlite:///dev.db'
class ProductionConfig(Config):
DEBUG = False
SQLALCHEMY_DATABASE_URI = os.environ.get('DATABASE_URL')
class TestingConfig(Config):
TESTING = True
SQLALCHEMY_DATABASE_URI = 'sqlite:///:memory:'
注意：SQLALCHEMY_DATABASE_URI 在不同环境必须显式指定，空值或默认值在生产环境会引发连接失败。
立即学习“Python免费学习笔记（深入）”；
- 环境变量优先级应高于硬编码值（如用
os.environ.get(...)） - 敏感信息（如密钥、密码）不要写死在代码里，务必通过环境变量注入
- 测试配置用
sqlite:///:memory:是安全的，但注意它不持久，每次运行都是新库
怎样动态选择配置类而不硬编码环境名
靠环境变量 FLASK_ENV 或自定义变量（如 FLASK_CONFIG）驱动选择，避免在代码里写死 if env == 'prod'。
典型加载方式：
config_name = os.getenv('FLASK_CONFIG', 'development')
config_class = {
'development': DevelopmentConfig,
'production': ProductionConfig,
'testing': TestingConfig
}.get(config_name, DevelopmentConfig)
app.config.from_object(config_class)
关键点：
-
FLASK_ENV已被 Flask 2.3+ 弃用，建议用自定义变量如FLASK_CONFIG - 字典映射必须覆盖所有可能值，缺失时 fallback 到开发配置更安全
- 配置类名和环境变量值要严格一致（区分大小写），否则静默失败
为什么 config.from_object 不会覆盖已存在的配置项
config.from_object 是「更新」而非「重置」行为：只设置类中定义的属性，不会清空已有 key。这导致两个隐患：
- 如果之前手动设置了
app.config['DEBUG'] = True，后续再from_object(ProductionConfig)，DEBUG仍为True—— 生产环境意外开启调试模式 - 某些扩展（如 Flask-SQLAlchemy）在第一次访问
app.config时就完成初始化，此时配置已被冻结
解决办法：确保 from_object 是首次配置加载操作，且不在中间件、蓝图或扩展初始化之后调用。最稳妥的位置是创建 Flask() 实例后、注册任何扩展前。
容易被忽略的是：用工厂函数（create_app()）时，常有人在函数末尾才调用 from_object，而扩展已在中间注册 —— 此时配置已失效。
