1樓：何志斌
目前看，最好的方式還是async和await。
2023年7月1日修改：也許使用者態多執行緒（協程）這種方式更好。我需要一些時間去實驗一下Go/Kotlin
2樓：king wt
真夠２乎的，你寫的接觸的，天天看的ＨＴＭＬ互動事件都是事件非同步驅動的，你天天用的ｌｉｎｕｘ伺服器是事件非同步驅動的。
如果程式不建立監聽，驅動隨機觸發的事件，而要每次使用者發出乙個請求，都重新建立邏輯計算，大家可以回石器時代玩了。
你不會寫不代表別人不會寫，你看不到不代表非同步不存在。
3樓：枕水
程式設計師最怕搞非同步問題，並行問題，哪怕看上去是乙個最簡單的鎖，邏輯簡單到沒有任何技術含量的鎖，真跑起來還是會出各種莫名其妙的問題，而且人類至今還沒有研發出能有效針對這類問題的測試工具，那何止是痛苦，簡直就是最大的痛苦。
所以現在我特喜歡一種新的思路：就是我不玩多執行緒多程序了，我寧可多失敗，也比伺服器直接跑死要好。你讓我幹什麼我就幹，直到幹不成為止，我不再考慮其他程序執行緒之類的情況，只管我這一畝三分地。
所以從直覺上，我推崇事件驅動。
看了看其他回答，看來大家也都很喜歡事件驅動型的啊，都被多執行緒程式設計搞怕了吧？
4樓：徐辰
先要澄清一下，「非同步IO」不是「反應式IO」，兩者也許在特定場景或者實現中看起來很像，但思路是完全不同的。
如果題主問的是「非同步IO」對應的最佳程式語言機制，答案毫無疑問是coroutine，雖然現在直接支援coroutine的語言其實並不多，但是能在一定程度上模擬這個效果的方法不少，Python的gevent就是乙個典型的「非同步IO」框架，其中模擬了coroutine功能；Erlang的actor更有代表性。
如果題主問的是「反應式IO」，那麼答案顯然是event+語言整合的併發。支援event的語言/框架很多，很多年前的VB都有，但是支援語言級併發[1]的就不算太多，Erlang算乙個，Go也算乙個。
無論「非同步IO」，還是「反應式IO」，都要求作者不能用傳統的線性思維組織程式，必須認識到乙個網路服務程式本質上就是乙個狀態機。
「非同步IO」還是「反應式IO」在這一點上的區別就在於，狀態切換是「顯式/同步」事件驅動的還是「隱式/非同步」事件驅動的。
要實現複雜的狀態機，最合適的程式語言機制當然是CPS[2]，可惜的是支援CPS的語言也不多，Scheme算乙個，想不起來其它的了。
5樓：樸靈
幾個觀點人的思維是線性的，但是生活中的行為有很多非同步。
非同步在作業系統層面廣泛存在。但是在業務中僅僅因為程式設計師的思維是線性的，導致非同步幾乎不存在於業務層面中。
用的最多的程式語言為什麼是C語言，甚至前幾名都和C相關 C C ，而最早的高階語言Fortran都排不上TOP10
木色 Fortran並不是乙個通用程式語言，只集中在科學計算裡 當然現在也用的不多 而C則是通用的程式語言，它是對彙編的一種抽象，而這種抽象恰到好處取得了功能性與便利性的平衡！ 梁少聰 C可是計算機語言界的 聖母 好麼。至於Fortran，上面vczh也說了，早期連遞迴都沒有，後來才慢慢改好的。用里...
為什麼說 C 語言是系統級程式設計的首選？
打醬油的瘋子 基本上都沒有說到點子上。C語言基本上就是彙編的直譯，不能更簡單了。整個C就是指標和位址，然後是數值運算，別無其他。唯一隱藏的就是暫存器分配。再多一點就是提供了彙編沒有的型別驗證保護，而這個也是可以去掉的，C語言真的不能再多了。再多說一句話，就是基本上彙編能做的C能做9.5成，最後0.5...
什麼是多正規化程式語言，其中的「多正規化」是什麼意思？
白喬 誰提的概念？本身也沒幾個正規化吧 面向過程的 物件導向的 函式式的 val repeat times Int,func Unit 最近迷上Scala了。 Thinking80s 程式設計正規化 Programming paradigm 其實就是計算機程式設計所使用的方法，是設計程式結構所採用的...