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后，只有监听该特定发送者的接收器才会触发——这给了你精准控制的能力。
如何安全地连接和断开信号接收器？
接收器函数（receiver）容易被重复注册，尤其是在热重载或测试中多次导入模块时。必须确保连接一次、断开可控，否则很容易出现意料之外的重复执行。
- 用
@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_context装饰你的回调函数，之后就能安全使用request和current_app了。- 或者更稳妥的做法：在信号发送时把需要的数据（比如
request.url、session.get('user_id')）作为参数传进去，回调里只处理纯数据，彻底绕开上下文问题。
信号本身不解决上下文问题，它只是消息管道。上下文管理得靠你提前拍平或显式传递，这才是真正的实战经验。
