石雕工艺精湛、形象生动鲜活。 门楼上的石门框是展翅飞翔的凤凰缕空浮雕。 门框右上方双翅展飞的凤脚踏祥云，身披祥云，回目翘望，祥云围绕凤的四周。尖喙，月牙形眼睑，突出的圆形眼球；曲颈；半月形花冠上清晰的花纹，鸡头下两块肉胡凸凹有别；展开内侧的飞翅上粗羽毛管，根根可数；长长的两尾甩在祥云中；缕空的云团曲绕。 门框左上方的是飞凰缕空浮雕。脚踏在祥云上，展开的双翅，曲颈回望，与凤深情对视；凰的头上没有凤美丽的花冠，嘴也有凤的前尖细后粗的形态的；展开的三尾也与祥云相绕，尾上粗羽毛管很清晰。这一组石雕，充分展示出了民间匠人的超凡艺术水平，只是不知是匠人有意或是无意，把凤凰的尾放错了位。民间传说凤是三尾，凰才是两尾，而浮雕上却凤是两尾，凰是三尾；也许是匠人在寓意凤凰相交并存，喻当时慈禧女人在执政吗？ 门楼大门前的方石礅，采用阴阳两刻手法。上层刻花纹，下屋却阳刻花、叶，两种刻法用在同一件石器上。花叶的刻纹精细，形状略有不同，却又相连相环。 祠堂内的四层柱础，下方上圆。比较特殊的是，柱础上面的石鼓直径要比中间两层的大，一粒一粒的圆鼓钉大小均称，间隔距离相等，密密麻麻的一圈。 鼓面是相连花叶，面宽而茎细；中间一层为六棱形，下层的六棱形把棱角磨成圆弧，刻粗厚花瓣和动物；与地相接是素面正方形，这种造型独特而承重力又强的柱础，充分表现了我国民间匠人的智慧。 村中民居保存较大的石水缸，也叫太平缸，是用来蓄水防火。缸长190cm，高80cm，宽90cm，内空也有175cm长、73cm宽。 据其主人杨培林说，此缸是因邻居家遭火后才制造的，用村南柴君水旁的石头开凿，因太重，只能用圆木放在缸下滚推进屋。正面雕“双凤朝阳”图，展翅飞翔的凤和凰互为相望，其尾相交，一轮红日在水缸的正中，水缸的两边另刻有悬草，采用的全是阳刻。在水缸的另一面刻有“大清光绪元年三月十二日立”字样。 村北老祠堂内神龛两边的麒麟石雕，右为麒，左为麟，而麟还带着一只幼仔。形象生动，画面圆润，动态感强。特别是麟与幼仔的互相凝望，更是惟妙惟肖。 麟面容微笑，眼睛里那种母性的慈祥，幼仔在母亲面前的憨萌娇态刻得非常逼真，这种石雕艺术充分表现了民间艺人高超的水准。祠堂的神龛雕这种仁兽，表达的是村民对美好生活的向往和祈盼。 另外村中还有两副旗杆石，分别立在村西进村的路口，村里人称这为“闱子”，在旗杆石上刻有“乾隆四十五年”字样，知此旗杆石立于清代中期。 木刻艺术与建筑力学的完美结合。 大皮口村两座祠堂里的木刻非常精美，选用承重的杂木，在粗厚驼峰上刻有各种动物。老祠堂的顶梁上的驼峰刻“狮子下地”；下梁的驼峰要大一倍，刻飞动貔貅；驼峰的木刻猛兽寓意深远，灵动猛兽的艺术美与梁柱承重的完美结合，高超地表现了湘南百姓的审美情趣与工匠智慧。 雄狮和貔貅这些猛兽，用于祠堂的梁架上，更有祛邪护家保平安的寓意，表达了建造者的良好愿望。 门上户对刻八卦图、摇钱树；窗子整体以“回”造形与卯榫之间花纹细刻，粗、细之间处理科学与美融合。 泥塑图案精细，艺术手法多样。 门楣上彩塑构思独特，寓意深刻，右为一摇钱树，左为一人骑马，既寓意“取经东归”，又为“得财而回”。这副彩塑嵌入墙内，墙的外砖很好地为图案遮蔽风雨，这也是彩塑为何存至今仍完好的原因。 墙上的外窗，用砖与泥灰塑成，方形窗的开口与泥塑成为一副完整的图案。 外墙博风板上的彩塑，貔貅与悬鱼草纹理清晰，圆润的画面突现图案的逼真与生动。 各式马头墙 三叠式的马头墙，高翘的墙角似鹰嘴向上突起，表现出庄重威严气势。 改良的人字封火墙。整体似人字墙，陡峭的“人”字头，下部两个墙角向上微翘，成一个抛物线。“人”字头上又砌成封火墙形，高高矗立在屋脊上，最上面塑以神兽向天仰望，这种封火墙造型把威严的气势展现得淋漓尽致。 有的封火墙的墙角泥塑各类神兽，以示守护村落。 大皮口传统村落里的石雕、木刻、泥塑艺术，可以说充分表现了永州民间艺术的最高水平。既有乡间绅士把自己对传统文化的理解表现在村落的建筑上，充分反映出民间乡贤绅士的文化自觉性，也有民间艺人对各种艺术手法的掌握，以及艺术作品中的文化内涵体现。 https://www.usreio.com/t/topic/261
大皮口传统村落里，明代以前的古民居已不见踪迹，离村不远的水坝应是其先祖拓荒时，为保村民生存的水源所建。清末民国初《零陵梅溪杨氏族谱》中，已经有“坝口”的记载，并把坝口里的水分享情况作了限制说明。“吾村自立宅开创以来，规模深厚。两处水源，别村异姓不占寸分。一处坝名‘无事’，古坝后名‘原坝’。 坝之下另有小坝，只许收其余水架车，不准开挖上坝。其原坝古沟，自坝起，至下观屋门口小坝止，宽一丈二尺。自小坝至社湾屋门口止，宽五尺。 凡草创修沟，遵依尺界挖铲，不准戽车。”谱中所载嘉庆二十四年的诉讼案中也有“坝口里”之名。水坝是大皮口先民在明代所建，也是大皮口现存最早建筑，至今仍造福于后人。 大皮口村坐东朝西，根据《杨氏族谱》上的大皮口村落图，清末村子的规模非常恢弘。 村南的柴君山水环村流入梅溪河，从小坝里岩洞引水入村的沟渠穿村而过，流入村前的田洞里。村北的水沟渠从另一山谷引入，从村后的田洞中环村而过，再流入村前的田洞里，这两沟渠符合谱书记叙，小坝沟渠不得超过五尺。 村中沟渠沿着村南五家堂北边横屋流出村。村北是一座宽大的三进四合院，四合院两旁是五栋独立的房屋，离屋不远有两个小高坡，还有一口水塘。小高坡为大皮口村阻挡北来的寒风，如今这小土坡和水塘已被用来建了新房。 有人说大皮口原是叫大坡口，后把“坡”字的偏旁“土”写丢了，便成了“大皮口”。这是村民口中流传的说法，其源于村北的这两个小山土坡。但是在族谱中的村名一直都是叫做“大皮口”。 村子的南北各有一条小路环村而向东延伸，现在地图上看到的是一条直道，从水口山镇而来，然后在村口分南北两条路环村向东，在村后又合成的一条直路到柴君山脚下。 大皮口村两路环绕成圆，村前村后各是一条笔直大路，大皮口村就像一根藤牵上的瓜。原村落有围墙围着，如今村落围墙早就没有了。 大皮口村古建筑保存较完好的是村南院落群，村民叫“五家堂”或“五房堂”，是杨开尧的儿子杨宏昭为他五个儿子杨太巍、杨太崑等人所建。祠堂内的烧纸盆有“光绪十九年夏”（1893）刻字，惜字塔有“光绪二十三年”（1897）刻字，由此可推知，五家堂应是清末同治与光绪年间的建筑。 这座民居院落于2019年被湖南省列入第十批省级重点文物保护对象。据《零陵梅溪杨氏族谱》上的大皮口村图，五家堂应是五座连屋四个纵巷道，也有人说是“五纵六横十二巷”。 五座连屋前面的照墙是宽阔的混水墙，院落前是塘、田，南面由三座独立的横屋环绕着，一座是门楼。五家堂巷巷相通，纵横相连，每栋屋之间用连廊相接，下雨天也可以走遍整个院落而不湿鞋。 院落里的门窗、户对、门楣等都采用了或刻或塑的艺术造型，其艺术精到，形式多样，非常精美，具有很高观赏性。 五家堂南侧的有一座门楼，但它不同其他村落的门楼。一般古村里的门楼会与村落建筑同一个方向，如永州江永上甘棠村的门楼就是这样的朝向，门楼要比主要建筑矮且窄小，只有两排梁架，对村内建筑起到一个防护作用。 而大皮口村的门楼与房屋主建筑不是同一个朝向，门楼面向西南方向，巷道屋是朝向西面，门楼与五家堂的建筑成钝角。与五家堂群建筑也不处在一个轴线上，而是处在院落群的南侧面。 大皮口传统村落的门楼比较高阔，非常恢弘大气。门楼为门屋的形式，有四排穿斗式梁架，每排五根木柱，中间两排的前檐柱立于大门外，用穿插枋与金柱相连。 大门前廊墙呈“八”字形，门槛前一对方形门当，方正的高大石门框，石门上框有浮雕。进入门楼不是院内的纵巷道，需要拐一弯道才能进入“五家堂”的纵巷道。 这种从门楼进入院内建筑的方式与道县楼田村的门楼布置有些相似。现门楼是近几年恢复建造，但基本规式没变，保存着原有的建筑格式。 在五家堂屋后是一座建筑面积宽阔的祠堂，祠堂朝向五家堂纵道，面向西，祠堂正厅前是大面积混水照墙，照墙外是五家堂的横巷道，祠堂从两侧门进入。 祠堂平面呈长方形，没有正前门而是在两侧山墙开大门。高大的三叠式马头墙与村其它建筑隔离。祠堂是一进式古建，进深不深，但面宽阔，两排四柱，柱与柱之间采用卷棚，似廊而不是廊。祠堂采用的抬梁式结构，其独特之处，三架梁、五架梁、七家梁合为一个三角形的整体，每排梁架只有两根木柱，即前后金柱，九架梁的两端就搁置在两根金柱柱顶。 五家祠堂这种减柱之法和三、五、七架梁合为一整体的做法，既省工又省料，体现出重要的力学原理，有较高的科学研究价值。祠堂内置一圆形石盆和一座方形石质香炉。 村子的北面据原村图是一座三进的四合院，环四合院而建的是几座独立成栋的房屋，四合院后有一座祠堂，这座祠堂较之五家堂的祠堂规模要小许多，时间早，于嘉庆二年所建，但其各种雕刻却美仑美奂。 大皮口传统村落另一独有的古建筑——惜字塔。惜字塔也叫“惜字楼”“焚字库”“焚纸楼”“字库”“圣迹亭”“敬字亭”“惜字宫”“惜字炉”等。它们用途相同——焚化字纸。 字纸是指不用的书和废弃的文稿等写有文字的纸片，不过，在惜字塔中焚化的实际上是文字，纸张只是作为文字的载体而存在。与用于烧金银纸的金炉不同，惜字塔是用于焚烧有文字的纸张的地方，表达的是古人“敬惜字纸”理念。 古人认为文字是神圣和崇高的，写在纸上的文字，不能随意亵渎，即使是废字纸，也必须诚心敬意地烧掉。古人这种理念主要是受科举制度影响。到宋代纸虽然比较普及了，但也是很昂贵的，一般人也买不起。 中国的惜字塔始建于宋代，到元明清时已经非常普及了。惜字塔通常是建造在市集街口、书院寺庙之内、道路桥梁旁边。 在自家院落或村内建惜字塔的，一般都是较富裕的人家或村落，大皮口传统村落建惜字塔，说明大皮口村自古以来就有尚学的风俗。 大皮口村惜字塔建在村南的村口边，柴君山溪流的西南岸，现为一新建房围隔。惜字塔以一小石山为基脚，凿三级石阶，用砖砌成的六层方塔，塔顶是三层宝葫芦造型，塔中空。 第三层建一石库门，石门上刻“仙境”两字。惜字塔祭祀的应是孔子或仓颉，村民说以前塔里立一坐塑像，供人们朝祀，后塑像被毁掉了。 那尊塑像究竟是佛还是孔子或仓颉，现不得而知。塔身有一石碑，刻记捐赠建塔人的名单，建塔时间为“大清光绪二十三年阳月吉日合村公立”。 惜字塔碑文：“六书制造以后，点横皆古圣精神，诸生披诵之余，残断亦作家心血。朽蠹而不经火化，飘零则难免涂污。是塔之建，本为吾村培筑催官，实劝地方敬惜字纸。 坚同石室，坐镇江流。惟祈珍墨仁人，爱书吉士：从此文章入化，经锻炼以生新；争看文笔高簪，干云宵而直上。”大皮口村建的这座惜字塔，不单单是鼓励村里的后生“读书做官”，也是希望村民“敬惜字纸”，读书人写出“出神入化”的好文章。 https://www.usreio.com/t/topic/261#h-1
最近在编译 GRPC 的时候遇到了一个奇怪的问题，现在没有找到 GRPC 编译上使用的编译器。 主要原因就是 Java 使用的 Maven 插件将新的 Apple 操作系统识别成了 protoc-3.11.4-osx-aarch_64.exe。 如果你的 GRPC 使用插件的版本不够的话，这个可执行文件是没有在中央仓库中找到了。 例如，我们使用的 3.11.4 的版本就没有找到了。 可以做的就是对使用的插件版本进行升级。 例如我们可以升级到 3.17.3 的版本。 在这个版本中，我们就可以看到我们需要使用的插件了。 查看 Maven 库中可执行文件的地址链接为：https://repo1.maven.org/maven2/com/google/protobuf/protoc/3.17.3/ https://www.ossez.com/t/grpc-macos-m1/14044
Discourse 的头部链接是没有办法自定义的，我们使用下面的这个插件来进行配置 可以从 Git 代码仓库中进行安装，有关这个插件的官方讨论地址为：Custom Header Links - theme-component - Discourse Meta 我们 Fork 了这个插件：Fork 后的插件的地址为：GitHub - Discourse-C/discourse-custom-header-links 安装效果 安装后的效果如下面的图片。 桌面 移动界面 因为移动空间的限制，我们不建议在移动界面中显示更多的内容。 安装方法 从 Git 代码仓库中进行安装。 进入后台中的主题管理，然后选择安装。 然后可以选择从 Git 仓库中进行安装。 在仓库地址中，输入你需要安装的仓库地址。 在本例中，我们使用的地址为：Discource-C/discourse-custom-header-links - discourse-custom-header-links - OSSEZ SRC 当然，你也可以使用官方的地址来进行安装的。 如果一切顺利，则显示安装成功。 当然，在这里，你需要选择应用的主题才可以让你安装的插件生效。 然后你就可以在你的界面中看到启用的插件了，并查看产生的效果。 https://www.ossez.com/t/discourse-custom-header-links/14043
当前公司因为设计上的问题广泛使用了 Protocol buffers。 在使用的过程中发现了很多 Protocol buffers 的使用问题和滥用，一个好端端的工具被用成这样也是比较郁闷。 下面就对使用中的问题进行一些小的总结。 Protocol buffers 用意 Protocol buffers 是为了加快网络数据传输，对传输数据进行压缩处理，通过通过暴露接口让程序之间能够更快的进行通信。 举个栗子，服务或者程序 A 需要获得用户的信息，但是获得用户信息的方法已经在服务或者程序 B 中定义了。 有几个解决方案。 A 再重写一次 B 中已经定义的方法，这个显然是最不经济的，何必重写，并且还造成冗余，不便于维护。 B 程序提供接口，然后我们通过 HTTP 的方式访问，获得返回的数据然后进行序列化和反序列化。 使用 Protocol buffers，B 程序通过定义 proto 文件的方式将 B 中的方法暴露出来，A 程序可以在程序中直接使用这个方法，如果 B 程序的方法改变了或者升级了，A 程序也不需要做太多修改，因为在 A 程序中直接使用了这个方法。 我们来重点说说使用场景 3。在这个使用场景中，数据交换还是使用的 HTTP，定义的数据传输格式是在 proto 文件中定义的。 如果 B 程序中的方法改变了，但是传输格式没有改变，这是不会影响到程序 A 中的方法的。 通过 HTTP 的数据传输进行了压缩，效率比普通不压缩的 JSON 数据更小。对网络来说更小的数据就意味更大的效率。 简单的解释就是使用 Protocol buffers 就等于在场景 2 上面给你重新封装了一层。 Protocol buffers 传输数据量 Protobuf 限制最大的数据传输量是 2GB。 在默认情况下是 64MB。 不要以为使用了 Protocol buffers 就可以毫无节制的传输任何大小的数据了，其实不是这样的，如果程序中方法返回的数据量过大，或者对象 List 过于复杂。 你自然就会遇到超过 Protocol buffers 传输限制的大小，然后抛出异常。 这个和程序的设计也有很大关系，我们当前系统恨不得传输整个表，都不知道怎么说好。 Protocol buffers 滥调用 没有人真正认真的维护 proto 文件，想怎么用怎么用。 结果的问题是：一个服务需要运行，需要启动其他 5 个服务才能在本地完成调试。 又因为每个服务的启动都占用端口，所以会导致各种方法进行交叉调用，让写好的程序非常难于在本地进行调试。 解决办法就是对每个服务的功能做出界定，不要过多的滥用 Protocol buffers 进行调用。 其实上面的问题都是人为导致的，再好的东西一旦滥用了，就是各种奇葩各种翔了。 https://www.ossez.com/t/protocol-buffers/14042
JVM 是 Java 的精髓部分之一。 Java 最开始是怎么来的？其实是从 C++ 上过来的，所以 Java 上面很多的面向对象特性都有 C++ 的影子。 C/C++ 最受诟病的是什么，就是指针，经常性的内存溢出。Java 说，算了，我们做个东西没有指针吧，这样程序就不会因为内存溢出而挂起退出了。得到的是经常性的空对象异常。 C/C++ 不仅仅有个编译的过程，还有一个过程叫做连接，这个也是经常出问题的地方，经常连接不上去。 不同计算机体系结构也不一样，大学应该有一门课程叫做《计算机体系结构》，主要涉及到 CPU，内存，存储，以及对字符和数字的处理上。 Java 就说，那么这样的话连接也出问题，编译好的代码也没法用，那我就用个虚拟机，然后让这个虚拟机在所有计算机体系结构上跑吧。 这个就是 Java 虚拟机的由来，JVM 是 Java 中非常重要的概念，帮你屏蔽掉了 Java 针对硬件环境中的各种痛点和不适。 https://www.ossez.com/t/java/14041
PHP 把压力大部分都丢给数据库了。 一个公司，一个查询，超过 10 个 join， 5 万左右实际数据级，512G 数据库内存，还经常锁表。 一个 PHP 文件，超过 2.5 万行代码，我都不知道他们怎么写的。反正在数据库上面调完 SQL 再拿回来用，连分页都没有。 这么大的 PHP 文件，连 IDEA 的代码分析都困难，IDE 都能被折腾死 Java 比较注意数据结构化定义，ORM 倾向在业务层处理数据，少用 Join。 PHP 上手确实容易，但是这代码实在是没有那么规范，再加上变量名命名的随意性，简直想死的心都有。 这 API 接口对 PHP 来说，毫无规矩可言，随便怎么跳转就怎么跳转，真的好想哭。 https://www.ossez.com/t/java-php/14040
在进行一次编译的时候，提示下面的错误信息： java: java.lang.ClassNotFoundException: org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor 问题和解决 如果你对 Hibernate 的元数据还是不非常了解的话，请参考文章： JPA 的 Metamodel 中的内容。 有关元数据生成器中的内容，请参看官方的：JPA Static Metamodel Generator 这里有几种使用方法： 我们使用了第一种的 Maven 配置方法： <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.8</source> <target>1.8</target> <compilerArguments> <processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor> </compilerArguments> </configuration> </plugin> 在我们的项目中和 lombok 的插件编译方法冲突了。 需要讲上面的配置方法通过 annotationProcessorPaths 来进行配置。 修改后的配置如下： <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>${maven-compiler-plugin.version}</version> <configuration> <release>${java.version}</release> <annotationProcessorPaths> <path> <groupId>org.hibernate</groupId> <artifactId>hibernate-jpamodelgen</artifactId> <version>5.4.33.Final</version> </path> <path> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.24</version> </path> </annotationProcessorPaths> </configuration> </plugin> 然后再次编译和运行项目，上面的错误就解决了。 通常官方文档需要认真参考下。 https://www.ossez.com/t/hibernate-metamodel/14038
提示的错误信息如下： D:\WorkDir\USRealEstate\Source-Code\Common\common\src\test\java\com\ossez\common\tests\ConfTest.java:28:9 java: cannot find symbol symbol: variable log location: class com.ossez.common.tests.ConfTest 原因和问题解决 这个问题可以通过修改 POM 文件来解决。 根据官方的说法，如果你使用了 JDK 9+ 以上版本的话，你同时需要在依赖和编译插件中加入 lombok 依赖。 如果你直接添加依赖，没有在插件中添加就会出现上面的错误。 解决办法就是，如果你使用的是 JDK 9+ 以上版本的话，需要添加 2 个位置。 然后再次运行就不会出现上面的提示了。 当然，你还需要在 IDEA 中启用插件。 https://www.ossez.com/t/lombok-idea-junit-variable-log/14037
对使用 lombok 还是有很多争议的，有些公司不建议使用，有些公司又大量使用。 我们的想法是：可以使用，但是不要滥用。 什么是 lombok Lombok是 一种Java™实用工具，可用来帮助开发人员消除Java的冗长代码，尤其是对于简单的Java对象（POJO） 。 它通过注释实现这一目的。 通过在开发环境中实现Lombok，开发人员可以节省构建诸如hashCode() 和 equals()这样的方法以及以往用来分类各种 accessor和 mutator的大量时间。 我们都知道使用 Java 定义对象的时候都会用到 Getter 和 Setter 方法。 虽然我们有工具帮我们快速生成这些方法，但是实际上还是有点麻烦。 lombok 就可以通过一行注释来实现所有的这些方法。 lombok 可以做的不仅仅是这个，还可以通过注释 @Slf4j 来帮你实现自动定义 log。 我们就不用写冗长的 private static final Logger logger = LoggerFactory.getLogger(ListingProcessor.class) 这句话了。 而且针对 log 的类不同，这句话也是不同的。 如何使用 如果使用 Maven 的话，直接添加下面的依赖到 pom 文件中就可以了。 <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.24</version> <scope>provided</scope> </dependency> IDEA 的插件是自动安装的，你直接启用就可以了。 IDEA 会提示你是不是在当前的项目中启用 lombok，你可以选择启用或者不启用。 随后就是在代码中使用注释就可以了。 如下面的代码，我们直接简化使用注解就可以了。 需要注意的是，使用 log 来标记日志。 这样看起来，代码就优雅很多，也能减少不少不需要的代码。 lombok 的原理和滥用 Java 程序的解析分为：运行时解析 和 编译时解析。 通常我们通过反射获取类、方法、注解和成员变量就是运行时解析。但是这种方式效率其实不高，要在程序运行起来才能解析。 这时候编译时解析就体现出它的价值了。 编译时解析又分为：注解处理器（Annotation Processing Tool）和 JSR 269 插入式注解处理器（Pluggable Annotation Processing API） 第一种处理器它最早是在 JDK 1.5 与注解（Annotation） 一起引入的，它是一个命令行工具，能够提供构建时基于源代码对程序结构的读取功能，能够通过运行注解处理器来生成新的中间文件，进而影响编译过程。 不过在JDK 1.8以后，第一种处理器被淘汰了，取而代之的是第二种处理器。 这样就导致了 lombok 对 JDK 的兼容性出现了一些问题。 当你更换 JDK 版本的时候，lombok 的版本也需要一并进行更换，否则你就会出现错误。 如果下面文章讨论的错误： Java 项目编译错误 Error:java: java.lang.ExceptionInInitializer 就是因为 JDK 不兼容的问题导致的整个项目无法编译。 如果上游系统中提供的fegin client 使用了 lombok，那么下游系统必须也使用 lombok，否则会报错，上下游系统构成了强依赖。 如果你需要对 getter 或者 setter 方法进行一些编码的话，lombok 也不是不能用，但是会有一点点的学习曲线。 综合上面的考虑， lombok 还是可以用的，但是不要尝试所有地方都用 lombok，避免滥用。 哪怕就是为了使用 @Slf4j 来考虑的话，也是值得的。 https://www.ossez.com/t/lombok/14036