Flask内置信号不够用，因其仅暴露少数预设信号，不支持自定义命名空间、临时禁用或跨应用共享；需借助blinker实现灵活的事件驱动逻辑，如用户注册后解耦触发邮件、日志、缓存清理等操作。
为什么 Flask 内置信号不够用？
Flask 自带的 signals 模块（如 request_started）本质是基于 blinker 实现的，但默认只暴露了少数几个信号，且不支持自定义命名空间、不提供信号临时禁用、也不支持跨应用共享信号。一旦你需要在用户注册后触发邮件发送、日志记录、缓存清理等多个独立逻辑，又不想让视图函数直接调用一堆函数，blinker 就成了刚需。
关键点：Flask 的 signals 是 blinker 的薄封装，真正灵活的信号管理必须直接用 blinker。
如何定义和发送自定义信号？
别写全局变量或手动维护回调列表——用 Signal 显式声明信号名，再用 send() 触发。信号名建议带业务前缀，避免冲突。
-
from blinker import Signal，不要从flask.signals导入（它只含预设信号） - 定义信号时加
namespace参数更安全：user_registered = Signal(doc='User registered', namespace='auth') - 发送时传入 sender（通常是 Flask app 或具体对象）和任意关键字参数：
user_registered.send(current_app, user=user_obj, ip=request.remote_addr) - sender 为
None时，所有接收器都会响应；指定 sender 后，只有监听该 sender 的接收器才触发
如何安全地连接和断开信号接收器？
接收器函数（receiver）容易被重复注册，尤其在热重载或测试中多次导入模块时。必须确保连接一次、断开可控。
立即学习“Python免费学习笔记（深入）”；
- 用
@signal.connect装饰器最简，但无法动态断开；适合常驻逻辑（如全局日志） - 更推荐显式连接：
user_registered.connect(handle_welcome_email, weak=False) -
weak=False是重点：默认为True，函数若无强引用会自动断开，导致静默失效；生产环境务必关掉 - 断开用
user_registered.disconnect(handle_welcome_email)，或传sender精确断开特定来源
Flask 请求上下文里怎么用信号不报错？
信号回调里访问 request、g 或 current_app 很常见，但 blinker 回调不在 Flask 请求上下文中运行，直接用会抛 RuntimeError: Working outside of application context。
- 解决方案不是“把信号塞进视图里”，而是用
copy_current_request_context包装回调： from flask import copy_current_request_context-
@copy_current_request_contextdef handle_async_task():# 这里能安全用 request 和 current_app - 或者更稳妥：在信号发送时把需要的数据（如
request.url,session.get('user_id')）作为参数传进去，回调里只处理纯数据
信号本身不解决上下文问题，它只是消息管道；上下文得靠你提前拍平或显式传递。
