Python上下文管理器：类实现与函数实现的优劣对比

Great question—this is such a common point of confusion when diving into Python context managers, especially since both class-based and function-based approaches seem to cover the same core functionality at first glance. Let’s break down their pros, cons, and when to reach for one over the other.

Pros #

• Clear state management: If your context needs to track complex internal state (like multiple resources, connection counts, or configuration values), using instance attributes (self.foo) is far more intuitive than relying on closure variables in a function. The __init__, __enter__, and __exit__ methods give you explicit places to initialize, set up, and tear down state.
• Inheritance-friendly: You can create base context manager classes and extend them with subclasses—great for reusing common cleanup logic across multiple contexts. For example, a base ResourceManager class that handles generic cleanup, with subclasses for database connections, file handles, etc.
• Explicit lifecycle boundaries: The separation of __init__ (pre-context setup), __enter__ (context entry), and __exit__ (context exit) makes it easier to handle scenarios where initialization needs to happen before entering the context (like validating configs upfront).

Cons #

• Verbose for simple use cases: Even a trivial context (like temporarily setting a variable) requires writing a full class with at least __enter__ and __exit__ methods. This adds unnecessary boilerplate compared to the function-based approach.
• Disjointed logic: The setup and teardown code lives in separate methods, which can make it harder to follow the full flow of the context at a glance—you have to jump between __enter__ and __exit__ to see the complete picture.

Pros #

• Minimal boilerplate: For simple, one-off contexts, this is unbeatable. You can write a fully functional context manager in 5-10 lines of code, with linear, easy-to-follow logic. Example:

  from contextlib import contextmanager
  import os
  
  @contextmanager
  def temp_environ(key, value):
      original = os.environ.get(key)
      os.environ[key] = value
      try:
          yield
      finally:
          if original is None:
              del os.environ[key]
          else:
              os.environ[key] = original
  

• Linear flow: All context logic (setup, yield, teardown) lives in a single function. You read top to bottom: setup happens before yield, teardown in the finally block. This makes it much easier to trace what the context does without jumping between methods.
• Seamless ExitStack integration: Managing multiple resources is cleaner here—you can nest an ExitStack directly inside the function, avoiding the need to track the stack as an instance variable like in a class. Example:

  @contextmanager
  def multi_file_reader(*paths):
      from contextlib import ExitStack
      with ExitStack() as stack:
          files = [stack.enter_context(open(path)) for path in paths]
          yield files
  

Cons #

• Limited state management: Complex state becomes messy with closure variables. Unlike class instances, you can’t easily track multiple, evolving state values without cluttering the function scope.
• Less flexible exception handling: While you can handle exceptions in the try/finally block, the class-based __exit__ method gives you direct access to the exception type, value, and traceback via its arguments. This makes it easier to decide whether to suppress an exception or propagate it, without extra except clauses cluttering your logic.
• No inheritance: You can’t extend a function-based context manager—if you need to modify its behavior, you have to rewrite the entire function or wrap it with another decorator, which is less straightforward than subclassing a class.
• Easy to make mistakes: Forgetting to wrap the yield in a try/finally can lead to missing teardown logic if an exception occurs during the context. While the @contextmanager decorator handles some edge cases, it’s still easier to slip up here than with the explicit __exit__ method.

• Go class-based if:
  • Your context needs to manage complex state or multiple related resources.
  • You want to create reusable, extendable context logic (e.g., a base class for all your app’s resource managers).
  • You need fine-grained control over the lifecycle (separate pre-context initialization from entry logic).
• Go function-based if:
  • You’re writing a simple, one-off context (temp settings, single resource handling).
  • You prefer linear, easy-to-read code without boilerplate.
  • You’re quickly prototyping and don’t need to extend the context later.

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