Joel Spolsky 於 2002 年提出 Leaky Abstractions 抽象洩漏定律
All non-trivial abstractions, to some degree, are leaky. 所有難以理解複雜的抽象機制，在某種程度上，都是有漏洞的。
因為軟體的開發與運作環境複雜，開發人員不可能自造所有的輪子，而必須依靠各種抽象化的機制（大部分是 API 函式庫）進行開發，在隱藏細節的環境下，進行開發。經過一個開發人員的實作與開發後，某個程度下，又多了一層抽象封裝。但這些抽象封裝機制，不可避免都會洩漏出底層的一些問題，洩漏出無法封裝的問題。
在使用者使用抽象化後的介面後，在遇到不可預期的問題時，就必須要去了解底層的細節，才能知道發生的原因，也才能解決問題與除錯。雖然抽象封裝節省了開發的時間，但踩雷與除錯所耗費的時間也不少。因此我們才會在很多 QA 網站中，找到一些其他人的踩雷經驗與技巧。有經驗的開發人員，也會因為這些經驗的累積，避開可能會遇到的問題。
以下是一些抽象洩漏的例子
TCP 是現今網路的基礎，大部分的網路溝通，都需要利用 TCP 的可靠傳輸協定傳送資料，但不可避免的是 TCP 的流量控制機制本身就是有缺陷的協定，網路無法在一個穩定的流量通道上進行傳送，延遲跟 throughput 的波動對於 TCP 來說，都是正常的現象。但一般來說，沒有經驗的開發人員是無法預知到這些問題。
SQL 查詢語言是關聯式資料庫的查詢語法，但某些 SQL 查詢語法卻是有性能差異的，例如
select * from table就會比select column1, column2 from table速度來得慢。另外因為 AP Server 跟 DB 是分屬不同機器的狀況下，查詢時把整個資料表的所有欄位都取出來，也會造成網路頻寬的耗費而影像整體效能。
當我們遇到了一項新技術，宣稱因為良好的封裝，可以加速開發時。這時候最好是停下來想想看，這樣的封裝是不是真的有帶來實際的效益，還是會因為採用了這樣的抽象化封裝，而帶來一些無法預期的問題。
我們曾經使用過可以在 ios 與 android 同時運作的開發工具，但最終因為封裝後的函式庫本身的限制，無法微調，且函式庫無法跟隨作業系統的更新就馬上更新，最終只能放棄而採用原生的方式開發。但這不代表這種工具是不好的，對於畫面簡單的應用程式來說，使用者種方式開發，確實會帶來一些好處，但要有心理準備，可能會遇到一些根本且無法解決的問題。
References
The Law of Leaky Abstractions – Joel on Software
為什麼任何系統都會存在Bug？什麼是抽象漏洞定律？ - 每日頭條
