被程序所有函数使用的变量是否适合设为全局变量以替代指针传递？

这是个非常实际的问题——很多人都会在「到处传指针」和「用全局变量省事儿」之间纠结，我来分享下我的看法和实践经验：可以这么做，但这绝对不是最优解，甚至在大多数场景下是个埋下长期隐患的坏主意。

先说说为什么不推荐直接用全局变量 #

哪怕现在所有函数都合法地在修改这个变量，全局变量依然会带来一堆麻烦：

• 未来扩展性的坑：现在所有函数都依赖它，但谁能保证以后不会加新函数？或者现有函数会不会被抽去其他项目复用？全局变量会变成隐形的强依赖，到时候你想复用某个函数，突然发现它绑着一个全局变量，要么带着变量一起搬（污染新环境），要么改函数（返工成本高），怎么都别扭。
• 调试难度飙升：出问题的时候，你很难追踪到底是哪个函数在哪个时机把变量改坏了。全局变量的修改是「无迹可寻」的，不像传指针，你能顺着调用链清晰看到谁拿到了变量引用。
• 并发场景的噩梦：如果以后程序要改成多线程，全局变量直接就是线程安全的重灾区。每个线程都能改它，你得加锁，但全局变量的锁很容易被忽略，或者加锁逻辑混乱，最后要么死锁要么数据竞争。
• 可读性大打折扣：新接手代码的人看函数，从签名里完全看不出它依赖了全局变量，得翻遍函数内部才能发现。而传指针的话，函数签名明明白白写着参数，一眼就知道这个函数会操作什么数据。

那如果所有函数都要用，有没有比全局变量更好的方案？ #

当然有，这里给几个常用的替代思路，兼顾便利性和代码质量：

• 封装成结构体，传递结构体指针：把这个变量（以及其他相关的共享数据）打包成一个结构体，每个函数都接收这个结构体的指针。这样既避免了全局变量，又能让所有函数访问同一个数据实例。比如用C语言举例：

  typedef struct {
      int shared_value;
      // 以后加新的共享变量直接往这里加就行
  } AppContext;
  
  void func1(AppContext* ctx) {
      ctx->shared_value += 1;
  }
  
  void func2(AppContext* ctx) {
      ctx->shared_value *= 2;
  }
  

  好处是函数的依赖清晰可见，扩展性强，后续维护也方便。
• 模块级静态变量：如果这些函数都属于同一个功能模块，可以把变量设为模块内的静态变量（比如C里的static），然后只对外提供操作这个变量的接口函数。这样变量的作用域被限制在模块内，不会污染全局命名空间，模块内的函数也不用传指针就能访问它。比如：

  // module.c
  static int shared_value; // 只有这个模块里的函数能直接访问
  
  void module_increase() {
      shared_value += 1;
  }
  
  void module_double() {
      shared_value *= 2;
  }
  

  外部代码只能通过模块提供的接口操作变量，避免了意外修改，比全局变量安全得多。
• 谨慎使用单例模式：如果这个变量确实是整个程序唯一的实例，且你能严格控制它的访问逻辑，可以考虑单例。本质上它还是全局状态，但通过封装的getter/setter函数，能在一定程度上限制修改行为，比如加一些参数校验或者日志记录。不过单例也要慎用，它依然会带来全局变量的部分问题。

总结一下 #

就算现在所有函数都在使用同一个变量，也不建议直接用全局变量。全局变量带来的隐患往往是长期的，会让代码变得难以维护、扩展和调试。更好的做法是通过结构体传递、模块级静态变量或者封装的单例来管理共享状态，既满足了所有函数访问同一个变量的需求，又保持了代码的清晰性和可维护性。

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