避免模块间依赖与避免事件作为全局变量，哪个更应优先？原因是什么？

在嵌入式RTOS开发场景下，避免将事件作为全局变量的优先级要高于避免模块间依赖，核心原因是全局变量带来的隐式耦合、调试难度和稳定性风险，远大于显式模块依赖的可控代价。

核心原因分析 #

• 全局事件的不可控风险：全局事件会让所有模块都能直接操作它，没有访问边界，一旦出现误触发、重复初始化或未初始化就调用的情况，很难定位问题源头；同时无保护的全局访问容易引发线程竞态，破坏RTOS的线程安全。
• 显式依赖的可管理性：模块间的显式依赖（如方法2中B依赖A的头文件）是清晰可见的，编译阶段就能发现依赖缺失，后续可以通过分层设计、接口抽象等方式优化，而全局事件带来的是隐式依赖——从代码结构上看不到模块间的关联，但运行时却强依赖对方的全局变量，这种暗箱式的耦合才是模块化的最大敌人。

两种实现方式对比 #

方法1：全局事件暴露实现 #

模块A定义全局事件，通过OS封装层头文件对外暴露，模块B直接操作全局事件：

// 模块A a.c
#include <os_wrapper.h>
event* a;
createEventFlag(a); // RTOS事件创建函数

// OS封装层 os_wrapper.h
extern event* a;

// 模块B b.c
#include <os_wrapper.h>
// ...
postEventFlag(a); // 直接触发全局事件

这种方式的致命问题：

• 事件无访问控制，任何模块都能修改或触发，误操作风险极高；
• 模块间依赖关系隐藏，B看似只依赖OS封装层，实际强依赖A的全局变量，初始化顺序错误会直接导致运行崩溃；
• 后期修改事件逻辑时，所有直接操作a的模块都要改动，维护成本极高。

方法2：封装接口实现 #

模块A将事件设为静态私有，对外提供封装后的操作接口，模块B通过接口触发事件：

// 模块A a.c
#include <os_wrapper.h>
static event* a; // 仅模块A内部可见
createEventFlag(a); // RTOS事件创建函数

// 用户封装的事件触发接口
void eventFlagPostWrapper(void) {
    postEventFlag(a);
}

// 模块A a.h
void eventFlagPostWrapper(void);

// 模块B b.c
#include <os_wrapper.h>
#include <a.h>
// ...
eventFlagPostWrapper(); // 通过接口触发事件

这种方式的优势：

• 事件被模块A完全掌控，外部无法直接访问，避免了误操作和竞态风险；
• 模块间依赖显式清晰，B明确依赖A的头文件，编译阶段就能发现问题；
• 后续修改事件实现（比如换成信号量、添加线程锁）时，只需修改A内部的接口实现，B无需改动，符合开闭原则。

总结 #

嵌入式系统对稳定性和可维护性要求极高，全局变量带来的隐患是长期且难以排查的，而显式模块依赖是模块化设计中可接受的代价——甚至可以通过进一步的接口抽象（比如定义通用事件触发接口，让A实现该接口）来降低耦合度。因此，优先保证事件的封装性，避免全局暴露，是更合理的设计选择。

内容的提问来源于stack exchange，提问作者Manali Bhadsalkar