Asyncio：一個充滿尖銳角落的程式庫

Python 的 Asyncio 程式庫自從在 Python 3.4 引入以來，一直被視為實現非同步程式設計的強大工具，特別是針對 I/O 密集型應用程式。然而，許多開發者對其設計和實作提出了嚴厲批評，認為其 API 設計複雜、易錯，且充滿「尖銳角落」，導致使用起來困難重重。以下將深入探討 Asyncio 的主要問題，並以香港廣東話改寫，解釋其挑戰以及替代方案。

首先，Asyncio 的取消機制是其最大爭議之一。根據技術文章指出，Asyncio 的取消採用邊緣觸發（edge-triggered）而非層次觸發（level-triggered），這意味著取消操作只會觸發一次。如果一個任務在取消後未正確處理，會導致「任務已銷毀但仍未完成」的錯誤訊息，讓開發者摸不著頭腦。喺香港嘅開發者社群入面，有人形容呢個問題好似「搵唔到條鎖匙仲要畀人話你唔小心」，因為程式碼可能喺完全唔同嘅地方出錯，debug 起來真是一個頭兩個大。

再者，Asyncio 的 API 設計過於複雜，尤其係低階 API 同高階 API 之間嘅鴻溝。官方文件建議新手使用高階 API，例如 asyncio.run()，但好多開發者因為唔熟，會唔小心用到低階 API，例如直接操作 event loop，結果搞亂晒程式嘅執行次序。喺實際應用上，好似你喺旺角街頭搵路，原本想跟地圖行，但點知畀一堆亂七八糟嘅路牌搞亂晒，行到半路先知走錯咗。呢種設計令到新手同有經驗嘅開發者都好易跌入陷阱。

另外，Asyncio 對於非同步程式設計嘅學習曲線好陡。好多開發者喺 Reddit 同 Hacker News 上面提到，學 Asyncio 好似「行入一個無底洞」，因為佢同傳統嘅 Python 程式設計方式差別太大。喺香港嘅程式設計圈子，唔少人會話：「點解要搞咁複雜？用 thread 或者 multiprocessing 唔得咩？」事實上，Asyncio 嘅設計初衷係為咗處理網絡 I/O，但喺文件 I/O 或者 CPU 密集型任務上完全幫唔到忙，呢點令好多開發者覺得佢用途有限。

相比之下，其他程式庫如 Trio 同 AnyIO 被認為解決咗 Asyncio 嘅好多問題。Trio 提供更簡單嘅 API，取消機制更加直觀，減少咗「尖銳角落」。AnyIO 則喺 Asyncio 嘅基礎上加入 Trio 嘅語義，保留兼容性嘅同時修補咗唔少設計缺陷。喺香港嘅技術討論群組入面，有人會話：「用 Trio 好似食住港式奶茶，順暢又舒服；用 Asyncio 就好似飲錯咗杯苦茶，飲完仲要自己洗杯。」

總括而言，Asyncio 雖然有其用處，但其複雜嘅設計同易錯嘅特性真是一個挑戰。對於想喺 Python 實現非同步程式設計嘅開發者，建議先了解清楚自己嘅應用場景，考慮係咪真需要用 Asyncio，或者試下其他更友善嘅程式庫如 Trio。想了解更多詳情，可以參考呢篇技術文章：https://sailor.li/asyncio。