大家好，我是老劉
老劉做Flutter開發有7年了差不多。
我記得早先的時候還經常有人討論為啥Flutter沒有選擇kotlin而是選了dart。
當時我羅列和很多原因，同時也説過我個人其實是很喜歡Kotlin的。
想當年，Kotlin 就是拯救我們脱離Java 苦海的。
優雅的 Lambda 表達式、絲滑的集合操作符，效率直接起飛。
但是這兩年我發現自己越來越不喜歡用kotlin 而是更適應dart了。
你可能會説：“老劉，這是因為你最近只寫 Flutter 吧？”
確實，Flutter的開發工作佔比重很大是一個因素。
但如果僅僅是因為框架綁定，還不足以讓我改變對一門語言的喜好程度。這背後，其實有着自己對編程的理解和思考。
Kotlin 很強，但 Dart 更香
Kotlin 確實是個強大的語言，各種語法糖簡直甜到心裏。
空安全、擴展函數、高階函數，用起來那是真香。
但是，這種強大是要付出代價的，而這個待機通常是開發人員的心智成本。
寫 Kotlin 的時候，我腦子裏經常要多跑一個線程：這塊邏輯是用 apply 還是 also？是用 let 還是 run？
// 這種糾結時刻都在發生，僅僅是初始化一個對象：
// 寫法1：用 apply (上下文是 this, 返回對象本身)
val view = TextView(context).apply {
text = "Hello"
textSize = 16f
}
// 寫法2：用 also (上下文是 it, 返回對象本身)
val view2 = TextView(context).also {
it.text = "Hello"
it.textSize = 16f
}
// 寫法3：用 run (上下文是 this, 返回最後一行結果)
val view3 = TextView(context).run {
text = "Hello"
textSize = 16f
this // 如果忘了這一行，view3 就是 Unit
}同樣的一個功能，可能有五六種寫法，每種都有細微的差別。這種問題在團隊協作時尤為明顯，每個人的風格都不一樣，看別人的代碼有時候得腦補半天。
最重要的是他會打破寫代碼時心流的狀態。
反觀 Dart，剛開始接觸時覺得它有點土。
但用久了你就會發現，這種“平平無奇”才是真愛。
Dart 的語法設計非常剋制，它不追求炫技，而是追求直觀。
寫 Dart 的時候，我不需要在大腦裏時刻繃着根弦去糾結語法細節，直接順着邏輯寫下去就行。
// 同樣的邏輯，Dart 的解決方案通常只有一種 —— 級聯操作符 (..)
// 不需要糾結是用 apply 還是 run，也不用擔心 this 和 it 混淆
var view = TextView(context)
..text = "Hello"
..textSize = 16;代碼寫出來，三個月後再看，還是能一眼看懂。
這種特質，讓我在開發時能更專注於業務邏輯本身，而不是語言特性。
這一點在日常開發中其實是非常重要的。
開發人員的邏輯思路不會經常因為語法問題而打斷，一方面能提高效率，另一方面也會大大減少心智負擔，不會寫一會代碼就感覺很累。
AI 時代的生存法則
讓我內心的天平徹底偏向 Dart 的最後一塊砝碼，其實是 AI。
在這個 AI 輔助編程的時代，我們必須認識到一個事實：目前的 AI 模型，本質上還是一個強大的模式匹配機器，它是個“直腸子”，遠沒有進化到能進行深度邏輯思考的程度。
而 Dart 這種平平無奇的語法，恰恰是 AI 最喜歡的。
因為它足夠簡單、直觀、顯式。AI 讀得快、懂的透、寫得準。
反觀那些擁有豐富語法糖和黑魔法的語言，雖然對人類專家來説寫起來很爽，但對 AI 來説，卻成了幻覺的温牀。過多的隱式上下文和多樣的語法選擇，大大增加了 AI 犯錯的概率。
在 AI 時代，誰的代碼能讓 AI 更好理解、更容易生成，誰就是贏家。
以前我們追求代碼要寫給人看，現在可能還要加一條——寫給 AI 看。簡單直白的代碼，不僅人類維護起來輕鬆，AI 輔助生成的準確率也會顯著提高。
這才是 AI 時代的生存法則：摒棄花哨，迴歸樸素。
重劍無鋒大巧不工
年輕的時候總想着怎麼實現最複雜的功能，怎麼把語言特性用到極致。
那時候覺得，能把一行代碼寫得像天書一樣難懂，才叫水平。
但隨着年歲漸長，寫過的代碼越來越多，填過的坑也越來越深，我開始慢慢領悟到“重劍無鋒，大巧不工”的真諦。
現在的我，編碼風格發生了巨大的轉變。不再追求那些花哨的語法糖和所謂的“黑魔法”，而是更傾向於簡單、直接、健壯的代碼。
舉個最直接的例子，以前我很痴迷於各種自動化的依賴注入框架。覺得寫個註解，對象就自動注入進來了，多酷啊，多省事啊。
// 以前覺得很酷的“黑魔法”
@Inject
lateinit var userService: UserService // 它是從哪來的？誰初始化的？完全是黑盒。但現在，我反而更喜歡手動管理依賴，甚至就是最原始的通過構造函數參數傳遞。
// 現在更喜歡的“笨辦法”
class UserViewModel {
final UserService service;
// 一切都在陽光下，沒有秘密
UserViewModel(this.service);
}看起來這種方式有點笨，寫起來也沒那麼靈動。但它的好處是顯而易見的：直觀、清晰。
數據的流向一目瞭然，依賴關係清清楚楚。出了問題，不用去翻框架源碼猜它是怎麼注入的，看一眼調用棧就能定位。
我們寫代碼，最終目的是為了解決問題，為了讓系統穩定運行，而不是為了炫技。
哪怕拋開 AI 不談，我也更願意寫這種一眼就能看懂的代碼。
因為它經得起時間的考驗，也經得起團隊協作的折騰。這把“重劍”，雖然沒有鋒刃，但揮舞起來，卻是最紮實的內功。
當然，必須要承認的是，如果是在構建一個依賴關係錯綜複雜的超大型系統，或者需要極其嚴格的解耦和動態替換實現，成熟的依賴注入框架依然是不可或缺的神兵利器。但在我們大多數的日常開發，尤其是 Flutter 這種重 UI、重邏輯直觀性的場景下，盲目引入複雜的框架，往往是殺雞用牛刀，反而增加了維護成本。
5. 總結
從最初沉迷於 Kotlin 的語法糖和“黑魔法”，到如今偏愛 Dart 的樸素與直觀，這不僅是編程語言的選擇轉變，更是對代碼本質認知的轉變。
另一方面這也是在強大的語法糖和簡潔的心智模型中找到一個更適合自己的平衡點。
在 AI 輔助編程日益普及的今天，簡單、顯式的代碼不僅降低了開發者的心智負擔，更成為了 AI 理解與生成的最佳載體。
摒棄花哨，迴歸代碼解決問題的本真，Less is More，這或許才是我們在 AI 時代應有的生存法則。
如果看到這裏的同學對客户端開發或者Flutter開發感興趣，歡迎聯繫老劉，我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。
覆蓋90%開發場景的《Flutter開發手冊》
