Flask-Migrate应在init_app函数还是独立运行脚本中初始化？

针对你提到的《Flask Web Development（第2版）》中Flasky示例的做法，以及和官方文档的差异，核心原因可以从以下几点来理解：

1. 适配Flask CLI命令的底层需求 #

Flask-Migrate的核心功能是通过flask db系列命令（init/migrate/upgrade等）提供数据库迁移能力，这些命令依赖Flask的CLI系统。而CLI工具需要在启动时直接获取已初始化的Flask应用实例和SQLAlchemy实例——如果把Migrate的初始化放在create_app()工厂函数内部，只有当你主动调用这个函数时才会完成绑定，CLI工具无法自动触发这个过程，自然没法执行迁移命令。

把Migrate放在根级脚本初始化，本质是让CLI工具能直接加载到绑定好的应用和数据库实例，不用额外配置去调用工厂函数。

2. 遵循关注点分离的设计原则 #

工厂函数create_app()的核心职责是创建并配置Flask应用实例，如果把数据库迁移的初始化逻辑塞进去，会让应用创建过程和数据库迁移逻辑产生不必要的耦合：

• 比如你需要创建一个不带数据库连接的测试应用实例时，工厂函数里的Migrate初始化会变成冗余甚至干扰的代码；
• 分离之后，应用的核心创建逻辑和迁移工具的初始化逻辑相互独立，更符合大型应用的模块化设计思路。

3. 兼容官方推荐的工作流（但可灵活调整） #

书中示例用根级初始化，是在推广Flask官方推荐的CLI工作流，但这并不意味着你必须改变python run.py的启动方式。你可以通过以下方式兼顾两种需求：

在根目录的run.py中同时完成应用启动和Migrate初始化：

from app import create_app, db
from flask_migrate import Migrate

# 创建应用实例
app = create_app()
# 初始化Migrate
migrate = Migrate(app, db)

if __name__ == '__main__':
    app.run()

这样你既可以继续用python run.py启动应用，也可以通过设置FLASK_APP=run.py环境变量，正常使用flask db系列迁移命令，不用改变原有的启动习惯。

总结 #

Flask-Migrate之所以被“特殊处理”放在根级，本质是因为它是依赖CLI的工具类扩展，需要提前绑定应用实例；同时也是为了遵循关注点分离，避免迁移逻辑污染应用工厂函数。你完全可以根据自己的项目需求调整初始化位置，只要保证Migrate能获取到正确的Flask应用和SQLAlchemy实例即可。

内容的提问来源于stack exchange，提问作者crabulus_maximus