python中的裝飾器是一種特殊語法糖，用于在不修改原有函數或類代碼的情況下為其添加額外功能。它本質上是一個高階函數，接受函數作為參數并返回新函數。使用@符號實現簡潔的裝飾方式，例如@timer為函數添加計時功能。裝飾器的核心價值在于非侵入性和可重用性，適用于日志記錄、權限驗證、緩存等場景。編寫自定義裝飾器時需注意：1. 使用functools.wraps保留函數元數據；2. 帶參數的裝飾器需嵌套三層函數結構；3. 多個裝飾器按自下而上順序應用；4. 類裝飾器可用于修改或替換整個類；5. 描述符和元類是更底層的“裝飾”機制。這些特性使裝飾器成為解決橫切關注點、提升代碼可維護性的強大工具。
python中的裝飾器，簡單來說，就是一種特殊語法糖，它允許你在不修改原有函數或類代碼的情況下，為它們添加額外的功能或修改其行為。你可以把它想象成一個包裝器，在函數執行前后做點什么，或者完全改變函數的功能，而這一切都發生在函數定義的時候。它本質上是一個接受函數作為參數并返回一個新函數的高階函數。
解決方案
要使用裝飾器，最直接的方式就是利用Python提供的@語法糖。這讓代碼看起來非常簡潔和直觀。
比如說，我們想給一個函數添加一個計時功能，看看它運行了多久。我們可以這樣寫一個裝飾器：
立即學習“Python免費學習筆記（深入）”；
import time import functools def timer(func): @functools.wraps(func) # 這一行很重要，后面會提到 def wrapper(*args, **kwargs): start_time = time.perf_counter() result = func(*args, **kwargs) end_time = time.perf_counter() print(f"函數 '{func.__name__}' 執行耗時: {end_time - start_time:.4f} 秒") return result return wrapper @timer def long_running_task(n): """一個模擬長時間運行的任務""" sum_val = 0 for i in range(n): sum_val += i * i return sum_val # 調用被裝飾的函數 long_running_task(1000000) # 輸出: 函數 'long_running_task' 執行耗時: 0.0450 秒 (類似)
在這個例子里，@timer 放在 long_running_task 定義的上方，等價于 long_running_task = timer(long_running_task)。timer 函數接收 long_running_task 作為參數，然后返回一個新的 wrapper 函數。當我們調用 long_running_task(1000000) 時，實際執行的是 wrapper 函數，它在調用原始 long_running_task 前后加上了計時邏輯。
裝飾器不僅限于函數，也可以裝飾類，但那通常涉及類裝飾器，概念上更進一步。核心思想都是通過包裝來擴展或修改行為。
裝飾器在實際開發中能解決哪些痛點？
在我看來，裝飾器最核心的價值在于它的“非侵入性”和“可重用性”。想象一下，如果你有幾十個函數都需要記錄日志、檢查權限或者做性能監控，難道你要在每個函數內部都寫一遍重復的代碼嗎？那簡直是噩夢。裝飾器就是為了解決這類橫切關注點（cross-cutting concerns）而生的。
首先，日志記錄和性能監控是它的經典應用。你不需要在每個業務邏輯函數里都塞滿print或者Logging.info，也不用手動計算time.time()。一個簡單的@log_calls或者@timer就能搞定，代碼干凈利落。這讓我們的業務邏輯層保持純粹，只關注“做什么”，而不是“如何被監控”。
其次，權限驗證和身份認證也是裝飾器大展身手的地方。比如一個Web框架，很多視圖函數可能需要用戶登錄后才能訪問，或者需要特定角色才能操作。你可以在這些視圖函數上加上@login_required或@permission_required(‘admin’)。這樣，當請求到達時，裝飾器會先檢查用戶狀態和權限，如果不滿足條件就直接返回錯誤，避免了在每個視圖函數開頭都寫一大段權限判斷邏輯。這極大地提高了代碼的安全性、可維護性，并且避免了漏掉某個權限檢查的低級錯誤。
再者，緩存也是一個非常實用的場景。如果某個函數的計算成本很高，但其結果在一段時間內是穩定的，我們就可以用裝飾器來緩存它的返回值。@cache 裝飾器可以檢查是否有緩存結果，有就直接返回，沒有才真正執行函數，然后把結果存入緩存。這對于提升API響應速度、減輕數據庫壓力等都非常有效。例如Python標準庫中的@functools.lru_cache就是一個很好的例子，它會自動處理緩存的過期和淘汰。
這些應用場景，無一不體現了裝飾器將通用邏輯與特定業務邏輯解耦的能力。它就像一個工具箱，里面裝著各種小工具，你隨時可以拿出來給你的函數“升級”，而不用去拆開函數內部的“發動機”。
編寫自定義裝飾器時，有哪些常見的陷阱或需要注意的地方？
雖然裝飾器用起來很爽，但自己寫的時候，確實有些地方一不小心就容易踩坑，或者說，有些最佳實踐是必須掌握的。
我個人覺得最常見也最重要的一個坑，就是被裝飾函數的元數據丟失問題。如果你直接寫一個簡單的裝飾器，像這樣：
def my_decorator(func): def wrapper(*args, **kwargs): print("執行前...") result = func(*args, **kwargs) print("執行后...") return result return wrapper @my_decorator def greet(name): """一個打招呼的函數""" return f"Hello, {name}" # print(greet.__name__) # 結果是 'wrapper' # print(greet.__doc__) # 結果是 None
你會發現 greet.__name__ 變成了 wrapper，greet.__doc__ 也丟失了。這在調試、文檔生成或者某些框架（如測試框架）依賴函數元數據時，會造成很大的困擾。解決辦法就是使用 functools.wraps。它會將被裝飾函數的 __name__、__doc__、__module__、__annotations__ 等屬性復制到包裝器函數上。
import functools def my_decorator_fixed(func): @functools.wraps(func) # 加上這一行 def wrapper(*args, **kwargs): print("執行前...") result = func(*args, **kwargs) print("執行后...") return result return wrapper @my_decorator_fixed def greet_fixed(name): """一個打招呼的函數""" return f"Hello, {name}" # print(greet_fixed.__name__) # 結果是 'greet_fixed' # print(greet_fixed.__doc__) # 結果是 '一個打招呼的函數'
另一個需要注意的，是帶參數的裝飾器。當你需要裝飾器本身也接收參數時，就需要再嵌套一層函數。這會讓新手有點暈，但理解了就清晰了：
def repeat(num_times): # 裝飾器工廠函數，接收參數 def decorator(func): # 真正的裝飾器，接收函數 @functools.wraps(func) def wrapper(*args, **kwargs): # 包裝器，執行邏輯 for _ in range(num_times): result = func(*args, **kwargs) return result return wrapper return decorator @repeat(3) # 這里的 repeat(3) 返回的是 decorator 函數 def say_hello(): print("Hello!") say_hello() # 輸出三次 "Hello!"
這里 repeat(3) 并不是裝飾器本身，它是一個“裝飾器工廠”，執行后返回一個真正的裝飾器 decorator，然后 @decorator 才去裝飾 say_hello。
此外，多個裝飾器的應用順序也需要留意。裝飾器是自下而上應用的，但執行時是自上而下。這意味著離函數定義最近的裝飾器（最下面那個）會最先被“包裝”，最上面那個裝飾器會是“最外層”的包裝器。
@decorator_a @decorator_b def my_function(): pass
這等價于 my_function = decorator_a(decorator_b(my_function))。理解這個順序對于調試和預期行為至關重要。
最后，類裝飾器雖然不常用，但它能直接修改或替換整個類。這比函數裝飾器更強大，也更復雜。通常用于框架層面的元編程，比如ORM框架中定義模型、注冊組件等。理解它的原理需要對Python的類創建過程有更深的認識。
除了函數裝飾器，Python還有哪些相關的“裝飾”機制？
當我們談到Python的“裝飾”機制，函數裝飾器無疑是最常見、最直接的。但如果把視野放寬一些，你會發現Python在很多地方都體現了這種“在不修改源代碼的前提下，增強或改變行為”的思想。
最直接的擴展就是類裝飾器。它和函數裝飾器非常相似，只不過它裝飾的對象是一個類。一個類裝飾器接收一個類作為參數，然后返回一個新的類（通常是修改后的原類）。這在需要對類進行統一處理，比如自動添加方法、修改類的屬性、注冊類到某個系統等場景下非常有用。
def add_timestamp(cls): """一個類裝飾器，給類添加創建時間屬性""" setattr(cls, 'created_at', '2023-10-27 10:00:00') # 示例，實際應是動態時間 return cls @add_timestamp class MyDataModel: def __init__(self, name): self.name = name # print(MyDataModel.created_at) # 輸出 '2023-10-27 10:00:00'
這里 add_timestamp 裝飾器直接修改了 MyDataModel 類，為它增加了一個 created_at 類屬性。類裝飾器常用于框架層面，例如django的admin.register裝飾器，或者一些依賴注入框架。
再深入一點，描述符（Descriptors）也是一種非常強大的“裝飾”機制。它們是實現了特定協議（__get__, __set__, __delete__方法）的類實例，當它們作為類屬性被訪問時，會攔截屬性的訪問行為。Property、classmethod、staticmethod這些內置的裝飾器，其底層就是通過描述符實現的。
- property 允許你把方法當做屬性來訪問，實現了屬性的“計算”和“驗證”邏輯，而外部看起來依然是直接訪問屬性。
- classmethod 讓方法綁定到類而不是實例，第一個參數是類本身（cls）。
- staticmethod 更是完全不綁定到類或實例，只是一個放在類命名空間下的普通函數。
這些都是通過描述符機制，在不改變你調用方式（obj.attr或Class.method()）的前提下，改變了它們實際的行為。
最后，雖然不是直接的“裝飾器”，但元類（Metaclasses）在更高維度上實現了對類的“裝飾”或“定制”。元類是創建類的類。通常情況下，我們創建類時，Python會使用默認的type元類。但如果你定義一個自己的元類，你就可以在類被創建時，控制它的所有行為，比如自動添加基類、檢查方法簽名、甚至動態生成方法。這比類裝飾器更底層、更強大，也更復雜，一般只在構建非常靈活和可擴展的框架時才會用到。
所以，從函數裝飾器到類裝飾器，再到描述符和元類，Python提供了一系列不同層次的工具，讓我們能夠以非常優雅和非侵入的方式，對代碼進行增強、修改和定制，這正是Python語言靈活性的一個重要體現。
