首先，你如何保證別人的輪子是圓的？很多企業是因為已經用過了很多方輪子才決定自己寫的。其次，每一個輪子也有各自物理限制和基礎需求，這些在企業內部未必一定能滿足。就好像你拿了兩個專業大礦車才用的，直徑都三四米，重量按噸算的輪子，跟我講要組裝一輛自行車？別說能組裝不組裝得出來，組裝出來了，你騎得動嗎？如果一味地在x86環境下，你會覺得什么輪子都可以用，但是你要是某天突然遇到一個mips環境，內存只有幾M的硬件環境，用著uclibc的底層和非linux的實時操作系統。你就會發現很多庫的引入也許根本就不現實，還不如自己徒手上一個來得簡單。對于高手而言，這些基礎io都是信手拈來的，可以提前規劃好優化方案和調用路徑，甚至可以提前計算出理論上限，滿足了項目要求就可以。何必引入一個不確定是否能滿足產品要求的庫呢？這類系統里，可能內核都是修改過或者裁剪過得，你如何可以保證引入的庫可以跑起來，編譯腳本可能都得自己寫，更別談移植過程中的各種奇怪bug與妥協了。此外就是你現在覺得可能有各種庫，但是當年并沒有，那么只能自己寫。又或者當年的情況，要支持多個環境，沒有一個庫可以支持那么多環境的。只是你參與的項目少而已罷了。舉個例子，你能列舉一個可以在nds游戲機里面跑的網絡庫嗎？又或者簡單點可以說明下有哪幾個異步網絡庫可以在linux2.6下面穩定跑，并且沒有任何問題？