React无需Redux基于Hooks实现事件派发监听的风险及替代方案咨询

• 内存泄漏问题：首先卸载逻辑未做防御性判断，清理时如果globalListener[actionName]已不存在会直接抛错；其次某事件名下所有监听器都被移除后，空的事件名对象仍会留在全局globalListener中累积占用内存；另外存储清理逻辑的useEffect依赖为空，如果组件运行过程中actionName动态变化，只会清理初始actionName对应的监听器，新事件名的监听器会永久残留。
• 闭包陷阱风险：useListener的依赖参数默认是空数组，当用户传入的回调引用了组件内部的state/props时，如果忘记手动把对应变量加入依赖数组，回调永远只能拿到初始值，且现有实现没有触发React的hooks依赖校验，不会有任何警告，问题很难排查。
• SSR不兼容：全局globalListener在服务端会被所有请求共享，会出现不同请求的事件串扰，比如A用户触发的事件被B用户的监听器接收。
• 维护性问题：事件名是字符串格式，没有命名空间隔离，不同业务模块容易出现命名冲突，意外触发其他模块的监听器；TS项目下也没法对事件名、payload做类型校验，拼写错误、传参错误只能在运行时发现。
• 并发渲染兼容问题：React18并发模式下，直接修改外部全局对象的更新不会被React的调度逻辑识别，可能出现事件触发和组件渲染不同步的异常。

无需第三方库方案 #

• Context改造方案：把监听器容器放在Context中，根组件包裹EventProvider提供实例，useListener和useDispatch都从Context读取实例，既解决了SSR请求串扰问题，还支持嵌套Provider实现局部事件域隔离，避免全局命名冲突。
• useSyncExternalStore改造：配合React18的useSyncExternalStore封装全局事件对象，保证并发模式下事件更新和渲染的一致性，不需要额外引入第三方依赖。
• 轻量useReducer方案：把事件队列存入reducer中，dispatch事件时仅向队列新增记录，监听器通过订阅队列变化触发，只有几十行代码不会冗余，还可以复用React内置的状态更新机制，天然规避闭包问题。

第三方库方案 #

• mitt：仅200B的超轻量发布订阅库，把mitt实例封装进Context就可以快速得到成熟的事件管理能力，自带off、once等边界处理能力，不需要自己处理监听器清理的各种异常情况。
• RxJS：如果事件流有防抖、节流、竞态处理等复杂需求，可以用RxJS的Subject封装事件总线，配合useSubscription使用，适合逻辑复杂的中大型项目。
• 现有状态管理库复用：如果项目已经引入Redux/Zustand/Jotai等状态管理库，直接用它们内置的action订阅能力即可，不需要额外引入新的概念，比如Zustand可以直接订阅特定action的触发，Redux可以通过middleware监听全局action。

内容的提问来源于stack exchange，提问作者Kerem atam