blueprint 本身不持有 app 实例，无法直接访问其他应用的上下文；它仅作为模块化资源容器，在被 app.register_blueprint() 调用时才挂载到具体应用并获得上下文，且严格绑定于该应用，不支持跨应用共享路由、配置或钩子。
Blueprint 本身不持有 app 实例，无法直接访问其他应用的上下文
Blueprint 是 Flask 的模块化组织工具，它只负责注册路由、模板、静态文件等资源，但不绑定到具体 app 实例。它在被 app.register_blueprint() 调用时才“挂载”到某个应用上，此时才获得 current_app 和请求上下文。这意味着：一个 Blueprint 里写的 url_for()、render_template() 或 g 对象，都只能指向它当前注册的那个 app，不能跨出这个边界。
多个 Flask 应用之间默认隔离，没有共享的 registry 或 event loop
Flask 没有内置的跨应用通信机制——每个 Flask(__name__) 实例都是独立的 WSGI 应用，有自己的 url_map、配置、扩展实例和请求生命周期。即使两个应用共用同一份代码，它们的 app.url_map 互不可见，Blueprint 也无法“看到”另一个应用的路由或 before_request 钩子。常见误解是“把两个 Blueprint 分别注册到不同 app 就能互通”，实际只会各自运行，零交互。
跨应用调用必须显式走网络或进程间通道
如果你需要让 A 应用触发 B 应用的逻辑，可行路径只有：
- 用
requests.get("http://localhost:5001/api/xxx")发 HTTP 请求（最常用） - 通过 Redis、RabbitMQ 等消息队列发事件
- 共享数据库表，用轮询或监听变更
- 用
multiprocessing或socket做本地 IPC（仅限单机）
注意：current_app._get_current_object() 或手动传入另一个 app 实例去调用其 test_client() 属于测试场景 hack，生产环境不可靠且破坏封装。
容易忽略的陷阱：蓝图内硬编码的 url_for() 会绑定错 app
比如你在 auth_bp 里写 url_for("main.index")，这个 "main.index" 必须已注册在当前 app 的命名空间里。如果该 endpoint 是在另一个 app 中定义的，运行时会抛 BuildError。更隐蔽的问题是：用工厂函数创建多个 app 时，若 Blueprint 在工厂外提前导入并调用 url_for，会因找不到 current_app 直接报 RuntimeError: Working outside of application context。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
