Lombok插件到底要不要用？看到很多網友對這個話題進行討論，推薦使用的網友認為，自動化配置也需要了解代碼背后的實現，技術人科普一下使用及注意事項也是好事。而不推薦使用的網友則認為Lombok本質上是一個預處理程序，最大的問題是你看到的代碼和編譯器看到的代碼不一樣，會導致很多問題無法及時發現，跟C的define類似，所以不推薦使用。那么，你們覺得Lombok插件值得使用嗎？

推薦使用的網友這樣說：

1、市場有需求就會流行，普惠性比較高，只要能提高生產力（節約開發成本，創造價值）的工具都是好工具。如果幾年后這個需求還在，還會有“lombok完善版”出現（這個作者可能是你我他）

2、我覺得作為現如今大部分的開發人員，在開發中面對的是如何快速的開發，而不是去想是否會破壞源碼的可讀性和完整性；所以我推薦使用。當然也有一部分資深程序員會認為不推薦使用；不做評論，

3、就像數碼寶貝進化似的，一開始進化的畫面很是詳細，到了后面因時間問題進化畫面不再是那么必要的后，閃個光就進化了，剛學java的確實不適合用，但是考慮到開發進度，還是很有必要去用的。

4、省去了手動創建getter/setter方法的麻煩，但大大降低了源代碼的可讀性和完整性，降低了閱讀源代碼的舒適度;看似沒有多么重要的小改動,其實反而是為了表面簡潔而簡潔。 說這句話的人我感覺你不適合干開發

5、代碼的功能是為了實現更多的功能，如果花時間去寫getter/setter，也不是程序開發者想要的，目的就是花最少的時間，實現最有價值的功能

6、用了lombok省了不少事，而且也不會給性能帶來那么重的負擔，手寫get set 早晚會因為手誤出bug，一個女孩會因為戴項鏈而被壓死嗎，明顯不會，一個團隊一塊做開發，統一用一個插件還統一不起來？真搞不懂不推薦的人的理由在哪里

7、非常贊同使用，人都不斷在在進化，機器也是一樣，更何況一幫程序員呢，一些簡單無意義的操作。為和要重復再重復？難道不應該留點精力去做其他的事情么？

8、我是一個極其討厭冗長代碼的人，真的看過去腦殼痛，也有強迫癥。所以必須使用lombok,如果真有特殊字段需要查看，可以單獨寫這個字段的get,set.大部分字段都跟咸魚一般，沒什么卵用。but，在公司內網開發，插件都下不了，所以公司開發還是生成的get,set.

不推薦使用的網友這樣說：

1、雖然省去了手動創建getter/setter方法的麻煩，但大大降低了源代碼的可讀性和完整性，降低了閱讀源代碼的舒適度;看似沒有多么重要的小改動,其實反而是為了表面簡潔而簡潔

2、實體類所有的內容還是字節構建的好,雖然可以使框架的用注解來代替一部分內容,可以一旦實體類中出現其他問題,就很難查找到問題,而且此框架省略的代碼,也可以使用工具自動生成,生成后,我們也可以自行更改內容,而不局限于注解動態生成的

3、為了簡介而簡介。而且現在的各種IDE自動生成代碼功能都很強大，并沒有節省多少事。最重要的是：只要有一個用這種東西，全組都被迫得用

4、脅迫使用！當你的源代碼中使用了Lombok，恰好你的代碼又被其他的人所使用，那么依賴你代碼的人，也必須安裝Lombok插件(不管他們喜不喜歡)，同時還要花費時間去了解Lombok注解的使用情況，如果不那么做，代碼將無法正常運行。使用過Lombok之后，我發現這是一種很流氓的行為。

5、存在即合理從來都是一個錯誤的言論。黑格爾的愿意是存在是有原因的。而Lombok的存在固然是有原因的，但是不使用的理由也是相當充分的。因此，還是看開發團隊的代碼規范吧。

6、索然省去了生成setter/getter，構造方法和toString的麻煩，但代碼可讀性降低；另當字段過多時，生成的含參構造方法的順序不確定；代碼運行需要配置相關插件

7、不推薦，在有些代碼不規范的項目里，如駝峰命名不規范，可能會導致一些未知問題，已在實際項目中遇到過兩次這種不清楚的問題，最后都是修改了get和set方法得到了解決。

8、眾所周知，java早期風靡的原因不是代碼優美、程序員能偷懶，而是程序員能夠花非常小的代價就能協同工作、項目能夠靈活的部署和可控的代碼管理。 再看lombok。。。很不java。。。 再說，那些用lombok的同事，你們用lombok可以，但是用完后，找個工具把缺少的代碼補回來再提交代碼會死嘛。。。點一點，不比你們每個類加個標簽要慢。

以上，就是小編整理的Lombok插件到底要不要用的內容，希望能幫助到大家哦！