写Python函数，什么时候该用全局变量？

免费编程软件「pythonpycharm」链接https://pan.quark.cn/s/48a86be2fdc0一个让我被同事喷了一顿的PR上周我提交了一个PR代码大概是这样的# config.py DEBUG True API_URL https://api.example.com TIMEOUT 30 MAX_RETRIES 3 # main.py import config def fetch_data(): url config.API_URL timeout config.TIMEOUT # ... 发送请求 if config.DEBUG: print(f请求URL: {url}) def process_result(data): for attempt in range(config.MAX_RETRIES): # ... 重试逻辑 if config.DEBUG: print(f重试第{attempt1}次)我用了好几个全局变量准确说是模块级变量。代码审查时同事发来一句话全局变量不是洪水猛兽但你也用得太多了一点。我愣住了。全局变量到底该不该用什么时候用是合理的什么时候是坏味道这个问题没有标准答案但有一些准则。今天我把这些准则整理出来帮你拿捏好用和不用之间的尺度。第一步先搞清楚我们说的是哪种全局变量在Python里全局变量这个词被用得很宽泛。实际上有三种不同的全局1. 真正的全局变量模块级变量写在.py文件顶层的变量整个模块都能访问。# settings.py APP_NAME 我的应用 # 这就是模块级变量 VERSION 1.02. 函数的全局变量用global声明的在函数内部通过global关键字修改的变量。counter 0 def increment(): global counter # 让函数可以修改模块级变量 counter 13. 跨模块共享的变量通过import在多个模块之间共享的变量。# state.py user_count 0 # module_a.py import state state.user_count 1 # module_b.py import state print(state.user_count) # 看到module_a的修改我们讨论的全局变量通常指的就是这三种情况。它们的共同点是生命周期贯穿整个程序运行期间多个函数或模块都能访问。第二步全局变量的优点——它确实有用在说缺点之前先承认一个事实全局变量不是原罪。有些场景用它代码反而更清晰。优点1配置信息天然适合用全局变量程序的配置参数API地址、超时时间、调试开关在运行期间基本不变而且很多地方都需要用到。把它们放在模块顶层所有函数都能方便地访问。# 这些放在模块顶层清晰且方便 DATABASE_URL postgresql://localhost:5432/mydb LOG_LEVEL INFO ENABLE_CACHE True如果用对象来封装反而会增加不必要的复杂度。优点2缓存和单例状态需要持久化有些数据需要在多次调用之间保持比如缓存字典、连接池、全局计数器。# 缓存结果避免重复计算 _cache {} def get_user(user_id): if user_id not in _cache: _cache[user_id] fetch_from_db(user_id) return _cache[user_id]这种全局缓存是合理的——它确实需要在全局范围内存在。优点3减少参数传递的噪音如果一个变量被很多层函数调用传递而且每个函数都只是路过它那么用全局变量可以减少参数噪音。# 不用全局每一层都要传递debug def level3(debug): if debug: print(level3) def level2(debug): level3(debug) def level1(debug): level2(debug) # 用全局只在一处设置到处可用 DEBUG True def level3(): if DEBUG: print(level3)当然这种便利性是有代价的后面会说。第三步全局变量的缺点——它确实有风险缺点1隐式依赖降低可读性看这个函数def calculate_discount(price): if DISCOUNT_RATE 0.5: # DISCOUNT_RATE从哪来的 return price * 0.8 return price * 0.9读代码的人得去模块顶部找DISCOUNT_RATE在哪里定义的。如果这个文件有200行这增加了认知负担。相比之下参数传递是显式的def calculate_discount(price, discount_rate): if discount_rate 0.5: return price * 0.8 return price * 0.9一眼就知道这个函数依赖了哪些输入。缺点2全局状态让测试变困难写单元测试时全局变量是噩梦。因为测试之间会互相影响。counter 0 def increment(): global counter counter 1 return counter # test1 assert increment() 1 # test2 assert increment() 1 # 会失败因为counter现在是2要让测试独立你不得不在每个测试前重置全局变量。这很麻烦也容易遗漏。缺点3并发问题如果你的程序用了多线程全局变量需要加锁保护否则会出现数据竞争。counter 0 def increment(): global counter counter 1 # 这不是原子操作多线程下会出问题多个线程同时执行这行代码可能得到错误的结果。需要用threading.Lock来保护。缺点4代码耦合难以重构全局变量像一条无形的线把很多函数串在一起。当你想要修改它的行为时需要检查所有用到它的地方。比如把DEBUG从布尔值改成字符串级别DEBUG、INFO、WARNING所有用到它的函数都得改。第四步什么时候该用——一个决策框架不要简单地禁止全局变量而是根据场景判断。我整理了一个决策树场景1配置类变量→ ✅ 可以放心用程序运行期间基本不变多个地方需要访问。# 合理 API_BASE_URL https://api.example.com/v1 MAX_CONNECTIONS 10 DEFAULT_TIMEOUT 30场景2缓存和共享状态→ ⚠️ 谨慎使用用之前考虑有没有更好的方式# 合理缓存查询结果 _user_cache {} def get_user(id): if id not in _user_cache: _user_cache[id] db.query(id) return _user_cache[id] # 但如果是复杂的状态管理考虑用类封装场景3函数间传递的临时状态→ ❌ 用参数代替如果某个值只是在几个函数之间传递应该用参数不要用全局变量。# 不推荐 current_user None def set_user(user): global current_user current_user user def get_user(): return current_user # 推荐 def process_user(user): # 直接传递user参数 validate(user) save(user)场景4常量值→ ✅ 可以放心用数学常量、枚举值、固定字符串。# 合理 PI 3.1415926 MAX_UPLOAD_SIZE 10 * 1024 * 1024 # 10MB DEFAULT_PAGE_SIZE 20按惯例常量用全大写命名。第五步不用全局变量用什么呢如果你决定减少全局变量有几种替代方案替代1封装成类把相关的状态和行为放在一个类里。# 全局变量方式 counter 0 def increment(): global counter counter 1 # 类封装方式 class Counter: def __init__(self): self.count 0 def increment(self): self.count 1 # 使用 c Counter() c.increment()当状态和行为绑定在一起时类比全局变量更清晰。替代2用函数参数传递# 不推荐 DEBUG True def log(message): if DEBUG: print(f[DEBUG] {message}) # 推荐 def log(message, debugFalse): if debug: print(f[DEBUG] {message}) # 调用时显式传递 log(启动完成, debugTrue)替代3用配置对象如果有大量配置参数用一个配置对象来集中管理。# 不推荐散落的全局变量 DB_HOST localhost DB_PORT 5432 DB_NAME mydb DB_USER admin DB_PASS secret def connect(): return connect_to_db(DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASS) # 推荐配置对象 class Config: def __init__(self): self.db_host localhost self.db_port 5432 self.db_name mydb self.db_user admin self.db_pass secret config Config() def connect(): return connect_to_db( config.db_host, config.db_port, config.db_name, config.db_user, config.db_pass )如果需要还可以从配置文件或环境变量加载配置。替代4用模块级别的单例Python的模块本身就是单例。如果你需要全局唯一的状态放在模块里是合理的。# state.py _data {} def set(key, value): _data[key] value def get(key): return _data.get(key) # 其他模块导入state使用这实际上还是用了全局变量但通过函数接口封装了访问方式比直接暴露_data要好。第六步几个真实案例案例1Web应用的配置Flask、Django等Web框架都大量使用全局配置。这不是问题因为配置在运行时基本不变。# Django的settings.py SECRET_KEY ... DATABASES {...} INSTALLED_APPS [...]✅合理。配置变量就是全局的这就是它们的设计目的。案例2日志记录器import logging logger logging.getLogger(__name__) def do_something(): logger.info(doing something)✅合理。日志记录器在整个应用中是唯一的用全局变量访问非常方便。案例3数据库连接池connection_pool create_pool() def get_connection(): return connection_pool.get_connection()⚠️需要谨慎。连接池作为全局单例是常见的但考虑一下如果将来需要多个数据库连接池怎么办用类封装会更灵活。案例4用户会话信息current_user None def set_user(user): global current_user current_user user def show_profile(): print(current_user.name)❌不推荐。用户信息是请求级别的状态不应该用全局变量存储。Web框架通常用request对象来携带用户信息。第七步一个参考标准——全局变量的3个问题在决定是否使用全局变量前问自己三个问题问题1这个变量在程序运行期间会变化吗不会常量→ ✅ 放心用会但变化极少配置→ ✅ 可以接受会频繁变化状态→ ⚠️ 考虑用类封装问题2有多少个地方会访问这个变量1-2个函数 → 考虑用参数传递3-5个函数 → 可以考虑用全局5个以上 → 考虑用配置对象或类问题3这个变量的用途是什么配置/常量 → ✅ 适合全局缓存 → ⚠️ 谨慎确保有清理策略临时状态 → ❌ 避免全局单例服务 → ⚠️ 考虑用依赖注入第八步代码中的信号如果一段代码中出现了以下信号说明全局变量可能用得太多了一个模块里有超过5个global声明函数里有超过3个global声明全局变量被修改的地方超过10处测试文件里需要setUp和tearDown重置一堆全局变量你无法在同一个进程里运行两次不同的测试状态冲突当你看到这些信号时考虑重构。一张决策表使用场景是否推荐原因推荐做法常量PI、MAX_SIZE✅ 推荐不变到处用全大写命名配置API_URL、DEBUG✅ 推荐基本不变集中管理放在settings模块缓存查询结果⚠️ 谨慎有用但容易失控用类封装提供清理方法单例服务logger✅ 推荐全局唯一方便访问模块级变量跨函数传递的临时状态❌ 避免增加隐式依赖用参数传递多线程共享状态⚠️ 谨慎需要锁保护用线程安全的数据结构用户会话信息❌ 避免请求级别不是全局级别用上下文变量或request对象回到开头的那个PR我那个PR被同事喷了之后我做了这样几件事区分了配置和状态DEBUG、API_URL、TIMEOUT是配置保留在模块顶层封装了需要变化的状态MAX_RETRIES其实在不同的场景下不同改成了参数传递移除了不必要的全局有些函数里用全局变量只为了少传一个参数我都改成了显式传递改完之后代码变长了但变清晰了。审查通过了。最后一句总结全局变量不是不能用而是要知道什么时候用、什么时候不该用。一个简单的判断标准如果这个变量是属性属于程序本身的配置或常量可以用全局如果这个变量是状态描述程序运行过程中的变化尽量别用全局。换句话说配置用全局状态用对象。记住这句话下次写全局变量的时候你会多思考三秒钟。这三秒钟可能就是好代码和坏代码的区别。