flask信号需手动集成blinker才能生效，内置信号仅为占位符；自定义信号须用blinker signal类创建并传入app实例发送；生产环境应通过配置控制启用与否。
Flask 里信号没反应？先确认 Blinker 是否已启用
Flask 默认不启用信号机制，即使你装了 blinker，flask.signals 下的信号（比如 request_started）也不会触发——除非你手动把 Blinker 集成进去。很多同学写了 @signals.request_started.connect 却收不到回调，卡在这一步。
实操建议：
- 检查是否安装了
blinker：pip install blinker（Flask 2.3+ 不再自带） - 确认没有设置
FLASK_ENV=development以外的环境导致信号被静默关闭（低概率，但测试时建议显式设为development） - 不要依赖
flask.signals的模块级信号对象直接使用——它们只是“占位符”，真正在用的是 Blinker 的Namespace实例
怎么注册一个自定义信号并安全发送
官方文档藏得深：Flask 自己不提供创建信号的 API，得用 Blinker 的 Signal 类。直接 import flask.signals 里的东西来发信号是错的，那只是预定义的几个内置信号。
实操建议：
- 在应用初始化前定义信号：
user_registered = Signal(doc="A new user has been registered") - 发送时用
user_registered.send(app, user=user_obj)，注意第一个参数必须是current_app或 Flask 实例，否则接收方拿不到上下文 - 避免在信号处理器里调用
app.app_context()或db.session.commit()—— 此时请求上下文可能已销毁，容易报RuntimeError: Working outside of application context
接收信号时为什么拿不到 request 或 g 对象
信号本身不自动绑定请求上下文。哪怕你在 request_started 里注册处理器，函数执行时 request 是可用的；但如果你发的是自定义信号，request 和 g 默认不可见。
实操建议：
- 需要访问请求数据？手动传进去：
my_signal.send(app, request=request, user_id=user_id) - 别在信号处理器里直接用
request.args等——除非你能 100% 确保这个信号只在请求周期内触发 - 如果必须用上下文，用
with app.app_context():包一层，但要小心嵌套和性能损耗
生产环境禁用信号的简单方式
信号有开销，尤其高频事件（比如每个请求都发一次）。Blinker 没提供全局开关，靠删掉 connect 调用太麻烦，也不利于配置化管理。
实操建议：
- 用配置控制：
if app.config.get("ENABLE_SIGNALS", True): my_signal.connect(handler) - 更彻底的做法：把
Signal实例替换成空对象（比如一个什么也不做的send方法），避免运行时判断 - 注意：
disconnect_all()只清当前命名空间，对跨模块注册的信号不一定管用
信号不是万能胶，它解决的是“某件事发生了，通知其他模块”这种松耦合场景。一旦开始在处理器里查数据库、发 HTTP 请求、改全局状态，就该怀疑是不是该换消息队列或领域事件了。
