这个问题其实挺有意思的，让我想起以前在实验室调小车的时候，看到学长留下的满屏幕的全局变量，血压都上来了，这和我学的「封装」「低耦合」根本不一样啊！但后来被现实毒打多了才明白：在工控领域做开发，和写软件本质上是两个东西。

举个栗子，你写个平衡小车的代码，核心任务是什么？是每毫秒读取一次陀螺仪数据，算PID，然后控制电机转速。整个过程就像流水线工人拧螺丝——数据从传感器进来，经过几个算法模块，最后输出到执行器。这时候你需要的变量是什么？可能就是一个全局的「姿态结构体」，里面装着翻滚角、俯仰角这些关键数据。这个结构体就像车间里的传送带，所有工位（函数）都围着它转：卡尔曼滤波函数改它，PID控制器读它，电机驱动函数再拿它算占空比……这时候如果每个函数都搞参数传递返回值，就像让工人每次操作都要拆包装再打包，效率反而拉胯。

再说说性能问题，单片机那点可怜的RAM和算力，根本经不起多层函数递归的调用。比如在STM32F103这种经典芯片上，全局变量直接放在固定内存地址，中断服务函数随手就能捞到最新数据。如果换成函数传参，每次调用都要在栈上开辟空间，万一递归深了或者中断嵌套了，分分钟栈溢出。还有些实时性要求变态的场景（比如电机堵转保护），多浪费一个时钟周期都可能烧MOS管，这时候全局变量直接访问就是最高效的方法。

不过话又说回来，这种全局变量大法能活到今天，主要还是因为工控场景的业务逻辑相对单纯。你想想，平衡小车需要处理「用户突然想连蓝牙换皮肤」这种需求吗？需要应对「同时有100个客户端请求姿态数据」吗？不需要。它的逻辑就是传感器→算法→执行器的单线程循环，变量就像车间的零件，从头到尾只属于这条产线，自然不用像前后端开发那样严防死守「变量污染」。

总结起来就是：单片机用全局变量就像大排档用一次性餐具——不是最优解，但是快、省、够用。真到了要做满汉全席的时候（比如无人机集群或者人形机器人），你还是得乖乖上RTOS，玩消息传递，搞内存管理。当代码量膨胀到几十万行，全局变量就会变成房间里的大象——你永远不知道哪个函数会突然踹它一脚。