目前在写一个基于Swing的区块加载小地图，第一次测试中得到了HeadlessException。经排查，在net.minecraft.client.main.Main.main()方法最后有一个把java.awt.headless设为true的操作，于是就在Mod加载阶段把它又设回去了，后来测试时也未发现任何问题。但是，个人感觉这一段代码应该不是白写的，那么他的用意是什么，硬是给他设回去会不会造成一些奇怪的问题？

我假定你是在 1.16.5 或附近的版本上，因为我也找到了。

……但不是在 main 方法里，而是在 Main 类的静态初始化块（Static Initializer）里。

原因也很简单，因为技术原因，在有 lwjgl3 的环境里使用 AWT 会导致崩溃。
https://hub.jmonkeyengine.org/t/lwjgl-v2-versus-v3/42125/20

还真是在<clinit>方法中（1.16.4），是我记错了
这么说，现在的Mod是不兼容MacOS的，那解决方案是不是就只有改用JavaFX或OpenGL了。如果改用JavaFX，部分简化的JRE将不被支持；如果改用OpenGL，要么得编写大量本地代码实现要么依赖LWJGL的API从而放弃对物理服务端的支持。虽然可以在客户端改用OpenGL，并在服务端保持原来的方式不变，但这种不一致性个人又觉得不大好。问一下有没有合适的解决方案。

你可以考虑不支持 macOS。



虽说有类似 BellSoft Liberica 这样的发行版还在 bundle 相关库，但大部分我知道的发行版都是没有 bundle 的，需要用户自行安装并配置 classpath。
所以如你所说，会是一个大问题，而且不只是「部分简化的 JRE」。


我建议你跳出思维定势：在服务器上的渲染非得要通过 LWJGL 完成？
我的想法是，在服务器上，区块加载小地图的数据是以 JSON 或者别的格式呈现的，由一套简单的 HTTP 后端API 暴露出来，然后在服务器启动时顺手启动一个 HTTP 服务器提供基于 HTML(5?) 的渲染。

个人认为放弃对MacOS的支持是不可取的
统一迁移到JavaFX看来也不可取
渲染部分确实可以用给出的方式实现，但是在目前的设计中还有一些需要与服务端直接交互的功能，如移动地图显示范围和手动加载区块，不知道这种方案中能否实现。
目前个人认为最合适的方法就是尝试将两种不同环境下的渲染分开，在物理客户端使用OpenGL，在物理服务端使用Swing（实际上原版的服务器GUI也是基于Swing搭建的）。

可以做一个 API endpoint 来实现增量请求。


发一个 POST 请求。