這個問題其實挺有意思的，讓我想起以前在實驗室調小車的時候，看到學長留下的滿螢幕的全域變數，血壓都上來了，這和我學的「封裝」「低耦合」根本不一樣啊！但後來被現實毒打多了才明白：在工控領域做開發，和寫軟體本質上是兩個東西。

舉個栗子，你寫個平衡小車的代碼，核心任務是什麼？是每毫秒讀取一次陀螺儀數據，算PID，然後控制電機轉速。整個過程就像流水線工人擰螺絲——數據從感測器進來，經過幾個演演算法模組，最後輸出到執行器。這時候你需要的變數是什麼？可能就是一個全域的「姿態結構體」，裡面裝著翻滾角、俯仰角這些關鍵數據。這個結構體就像車間里的傳送帶，所有工位（函數）都圍著它轉：卡爾曼濾波函數改它，PID控制器讀它，電機驅動函數再拿它算佔空比……這時候如果每個函數都搞參數傳遞返回值，就像讓工人每次操作都要拆包裝再打包，效率反而拉胯。

再說說性能問題，單片機那點可憐的RAM和算力，根本經不起多層函數遞歸的調用。比如在STM32F103這種經典晶元上，全域變數直接放在固定記憶體位址，中斷服務函數隨手就能撈到最新數據。如果換成函數傳參，每次調用都要在棧上開闢空間，萬一遞歸深了或者中斷嵌套了，分分鐘棧溢出。還有些即時性要求變態的場景（比如電機堵轉保護），多浪費一個時鐘週期都可能燒MOS管，這時候全局變數直接訪問就是最高效的方法。

不過話又說回來，這種全域變數大法能活到今天，主要還是因為工控場景的業務邏輯相對單純。你想想，平衡小車需要處理「使用者突然想連藍牙換皮膚」這種需求嗎？需要應對「同時有100個用戶端請求姿態數據」嗎？不需要。它的邏輯就是感測器→算法→執行器的單線程迴圈，變數就像車間的零件，從頭到尾只屬於這條產線，自然不用像前後端開發那樣嚴防死守「變數污染」。

總結起來就是：單片機用全域變數就像大排檔用一次性餐具——不是最優解，但是快、省、夠用。真到了要做滿漢全席的時候（比如無人機集群或者人形機器人），你還是得乖乖上RTOS，玩消息傳遞，搞記憶體管理。當代碼量膨脹到幾十萬行，全域變數就會變成房間里的大象——你永遠不知道哪個函數會突然踹它一腳。