昨天到公司看到有人在羣裏把go跟java的interface做比較，提出go宣稱的“非侵入式”好像也沒那麼好用，甚至跟java差不多。但實際上go語言的接口設計並不只是語法本身，也包含了開發流程跟思維方式在裏面，下面把當時在羣裏的回答整理一下放出來。
其實可以這樣來理解：
Java語言的開發風格是設計先行，即先定義規範，然後去挨個實現（就是先定義有什麼方法，然後再寫出來方法體）。
而go語言是“先做再說”，即先把功能實現，然後抽取出接口。
在實際開發流程中，早先的從文檔到代碼的流程，確實Java更符合。但是開發流程本身也是在發展的，比如後來居上的敏捷流程就讓Java出現了雪崩的感覺（給interface加個東西，所有聲明implement該interface的都會報錯）。但是go就比較貼合這種流程，首先出現的是具體幹活的實體，實體多了才抽象出的接口，有了接口之後新寫的代碼可以使用interface作爲參數類型，同時不會導致原有代碼編譯失敗。這就允許開發者隨意在未來的任何時間來重構代碼，或者不做任何修改，這纔是“非侵入式”。
羣裏當時那問題，舉例說定義了“插座”這個接口，定義“微波爐”和“空調”去實現這個接口，後來“插座”多了個“開關”方法，就導致“微波爐”和“空調”也需要實現“開關”這個方法。我當時覺得他說的插座應該是想說能插電的設備，於是在回答的時候用的是“電器”，對這個問題我是這麼回答的：
然後說下你的問題，在java中可能是先在設計階段，就定好了插座、微波爐、空調及他們之間的關係。後面設計變更加上了“開關”這個方法。但是go語言的風格是用什麼就做什麼，需要有東西加熱食品，就先做微波爐，需要有東西調節氣溫，就做出個空調。然後發現公共部分可以抽象出來一個“電器”接口，於是就有了這個interface。這一過程的任何階段，在go語言風格中都是編譯通過的，至於是否需要把原來以空調或微波爐爲參數的func重構爲以電器，就可以根據實際情況來了。然後“開關”這個方法也不是憑空出現在接口中的，而是在實際開發中，發現微波爐需要有“開關”功能，然後給微波爐實現了；然後發現空調也用到了“開關”功能也加上了，這個時候開始思考是不是“電器”都需要“開關”呢，於是電器這個接口就有了“開關”。
實際上人不可能一開始就把東西設計的很完美，所以先定義後實現的路子走下來就是，設計變更帶來的改動很大。而go這種先實現好實體，然後抽象出接口的思想，就更貼合實際。所以說go語言的interface設計不只是語法，更是一種思維方式。實際上Rob Pike在GoogleIO上講go語言對併發支持的由來，就是“real world”本身就是很多事情在各自獨立互不影響的進行着。
略表拙見，如果有大佬路過發現哪裏不妥的感謝指正！