對待這個問題，我建議用辯證的角度去看待！首先我們來看只有final沒有static的情況，也就是說每個實現類裡面都會有一個名字和值都一樣的變數（final強調不準改變引用地址），那麼在初始化相關實現類的時候，都會單獨為這個屬性開闢一個儲存空間，這個時候問題就來了--》不覺得很浪費記憶體嗎？如果我用static關鍵字修飾了，不管你建立多少個實現類例項，他們都共享這個成員屬性並且記憶體中也只會開銷緊夠儲存這一個屬性的記憶體，而不會每個例項都去開銷這個屬性所需的記憶體，這是為毛要用static。反過來，我們看看不用final，只用static的情況，打個比方我們有A，V（名字取的不錯）兩個實現類，A類中的某個函式需要改變這個屬性的值為50才能使邏輯正確，B類中的某個函式需要改變這個屬性的值為100才能使邏輯正確，那麼問題來了，A類中的函式改成了50美滋滋，B類中的屬性也要變成50啊！所以B類在被運用的時候就報錯了，這個時候就造成了屬性歧義的問題，然而我們加上final這個關鍵字就不一樣了，開發看到這個屬性就知道不能再依賴這個屬性寫邏輯了，所以就自己另寫屬性，也就避免了後面的奇異性問題。。。或者我們從書本的角度來說，介面本來就是最高層次的抽象，你給我在裡面定義普通變數（我至少覺得變數一點不具抽象概念），玩呢？所以直接定死屬性值，他的作用我們暫時不用考慮，但是亂用它的風險我們還是規避，僅此而已。或許現在隔壁老王出來說，那我既不用static也不用final為毛也不行呢？我就想說你這個腦子是怎麼做到綠萬千男人的大事的？介面本來就是為了充分利用多型特性來增加框架擴充套件性，你在接口裡面定義一個name屬性，實現類都要去利用它，那萬一有的需求根本不需要用到這個屬性，而只是單純的想擴充套件架構呢？放在這裡好看嗎？對於這個情況，無論是官方還是個人意見都是在實現類定義自己需要的屬性，避免屬性值歧義和沒有必要的耦合度，所以你在介面中不能也是沒有必要去定義一個普通屬性，解答完畢，話說市面上的解答花樣多的我都看暈了，但是麻煩不能講清楚真心別亂說，容易誤導人。謝謝。