如果認為libevent和boost只是高效的網(wǎng)絡庫，那題目觀點確實是個大問題。libevent和boost雖然主要是用在網(wǎng)絡不假，但是更多的是體系，全家桶，內存，事件循環(huán)，回調方式，數(shù)據(jù)結構一起用，于是問題就來了。

一個傳輸通訊服務大概可以分為三層：底層網(wǎng)絡io(比如epoll)，協(xié)議解析，執(zhí)行功能。配套的還需要相應的內存模型，比如分配回收、buffer等等。

那么部分對于三五年一線c研發(fā)來說，網(wǎng)絡io應該是手到渠成的，再不濟一周也可以做完，甚至內存模型，消息循環(huán)，和基本數(shù)據(jù)結構組織，數(shù)據(jù)結構關系的設計都比寫一個網(wǎng)絡io要復雜得多。所以通常項目重頭還是在協(xié)議解析與執(zhí)行功能這兩部分，網(wǎng)絡io大多是隨手寫的。

就我個人而言，用boost也有些日子了，但是我不敢說我多了解，現(xiàn)成的asio模型套用，然后bind協(xié)議解析，再回調功能，如是而已，很多參數(shù)用到了或者有疑問了也需要大量時間閱讀文檔，感覺麻煩，又愛又恨，早幾年自己寫了一個小模型，有項目了直接就用了，除非核心項目時間緊迫，怕?lián)L險或者影響進度（畢竟現(xiàn)成庫雖然用起來不順，但是開發(fā)時間是可控的），會優(yōu)先考慮boost，libevent，或者nginx二次開發(fā)，或者優(yōu)先自帶網(wǎng)絡io的開源項目或者庫。

然后就是大佬們都有脾氣，有些大佬可能本身就不認同boost庫或者這庫那庫有多好，因為鄙視而不用。