_create_app() 不能在模块顶层调用，否则会提前触发扩展初始化和蓝图注册，导致配置未加载、db 未绑定而报错；所有扩展须在 extensions.py 中定义为未绑定占位符，并在 _create_app() 内通过 init_app() 绑定。
为什么 _create_app() 不能在模块顶层调用
_create_app() 必须是函数，不能在模块顶层执行，否则会立刻触发 Flask 扩展初始化、蓝图注册等操作，而此时配置还没加载、db 等扩展对象也尚未通过 init_app() 绑定到 app 实例。常见错误现象是导入时就报 RuntimeError: Working outside of application context 或 AttributeError: 'NoneType' object has no attribute 'query'。
- 所有扩展（如
SQLAlchemy、LoginManager）必须提前定义在独立文件（如extensions.py），仅实例化，不传app -
_create_app()内部才调用db.init_app(app)、login_manager.init_app(app) - 蓝图注册（
app.register_blueprint()）必须放在app.config.from_object(...)之后，否则url_for()在模板里可能解析失败
蓝图里怎么安全导入模型和工具函数
直接在蓝图模块顶部写from app.models import User 很容易引发循环导入，尤其当 models.py 又反向依赖 app.db 时。正确做法是延迟导入或通过上下文获取。
- 在视图函数内部导入模型：
def user_list(): from app.models import User return User.query.all()
- 公共工具（日志、权限装饰器）统一放
core/utils.py，不依赖 app 或 db，各蓝图直接导入无风险 - 需要访问当前用户？用
g.current_user，配合@app.before_request钩子从 token 或 session 加载，避免蓝图之间互相 import 用户模型
extensions.py 是怎么切断循环链的
把db = SQLAlchemy() 这类扩展定义从 __init__.py 搬到 extensions.py，本质是让它们变成“未绑定的占位符”。所有模块（models.py、auth/views.py）都从这里导入 db，但不会触发初始化逻辑。
-
extensions.py中不能出现from flask import Flask或任何 app 相关引用 -
models.py继承db.Model是安全的，因为此时db只是个空壳；真正建表、查询能力由init_app()注入 - 若误在
extensions.py里写db = SQLAlchemy(app)，就会立刻要求app存在，循环导入立即复现
CLI 命令和 init-db 怎么绕过导入时机问题
flask init-db 这类命令常因提前导入模型而失败，根源是命令模块在应用创建前就 import 了 models，而 models 又试图访问未初始化的 db。
- CLI 命令必须注册在
_create_app()函数体内，用app.cli.add_command() - 初始化数据的逻辑（如
create_default_roles()）要包裹在with app.app_context():中执行 - 不要在命令函数外直接调用
User.create()；确保所有 ORM 操作都在 app 上下文内
复杂点在于：循环导入往往不是单点问题，而是配置、扩展、模型、蓝图、CLI 五者耦合导致的链式故障。最容易被忽略的是——你以为修复了路由导入，结果 models.py 里一行 from app import db 就又把整个链拖垮。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
