企业官网建设流程全解析

在 macOS 上第一次双击启动一个 2014 年的老版本游戏，画面没出来，日志先刷了一屏红色，最后一行写着跟 OpenGL 上下文创建失败有关。换成较新的机器，情况更糟：进程直接退出，连崩溃报告都没生成。这不是个例，凡是把这套老版本搬到 Apple Silicon、新版 Linux 桌面、或者配着高刷屏的 Windows 机器上，几乎都会撞上同一堵墙——当年那套基于 LWJGL 2.9.x 的渲染与输入底座，和今天的操作系统、驱动、JVM 已经对不上话了。

LWJGL3ify就是冲着这堵墙来的。它做的事情说起来一句话：把老版本 Minecraft 里那套 LWJGL2 的调用，整体换成 LWJGL3 的现代实现，同时尽量不惊动上面跑的成千上万个模组。这不是简单的换 jar 包，因为 LWJGL2 和 LWJGL3 之间的 API 断层相当深，涉及窗口、输入、OpenGL 上下文、音频四套子系统。它适合的人群很明确：还在维护或游玩 1.7.10 生态的整合包作者、模组开发者，以及单纯想在 M 系列芯片或新版系统上把老存档跑起来的玩家。如果你只是想随便玩个新版本，这项目对你意义不大；但如果你手上有一个跑了几年、模组数量三位数的老整合包，那它可能是唯一能让你继续用下去的方案。

1. 2014 年的渲染底座，为什么在今天会彻底趴窝

要理解 LWJGL3ify 的价值，得先搞清楚 LWJGL 到底替游戏干了什么。LWJGL 全称 Lightweight Java Game Library，本质是一层 JNI 封装：把 Java 调用翻译成对 OpenGL、OpenAL、GLFW 这些 C 库的调用。游戏代码里每一句glDrawArrays、每一次键盘事件读取，最终都落到这层封装上。1.7.10 那个年代用的是 LWJGL 2.9.x，这套库的窗口管理走的是各平台自研的 native 代码，macOS 上走的是已经废弃的 Carbon/Cocoa 老接口，Linux 上走 X11，Windows 上走 Win32 窗口过程。

问题就出在这套"自研"上。它当年是为了兼容 OpenGL 2.1 时代的老硬件写的，代码路径十几年没大改。现代操作系统的图形栈早就换了一轮：macOS 从 Mojave 开始收紧 32 位支持、Catalina 彻底切断，随后 Metal 成为主推图形接口，OpenGL 被标为 deprecated；Apple Silicon 用 arm64 指令集，老库的 x86 native 只能靠转译层跑，性能和稳定性都打折扣；Linux 这边 Wayland 逐步取代 X11，HiDPI 缩放和输入法处理全变了；Windows 上现代显卡驱动对旧版 OpenGL 兼容层的支持也在收窄，尤其是对wglCreateContext这类老路径。

具体表现可以列成一张表，我这些年收到的反馈基本都落在这几类里：

这张表里任意一条，都足以让一个玩了五年的存档变成砖。而 LWJGL3ify 的思路是把整层底座替换掉，不是打补丁，是换地基。LWJGL3 用的是 GLFW 做窗口和输入抽象，GLFW 本身就维护着 macOS、Windows、X11、Wayland 四套后端，社区活跃，新硬件新系统的问题基本都在上游解决了。换成它，上面那张表里的大部分条目会自然消失。

1.1 换底座不是升级依赖那么简单

很多人第一反应是：那我把libraries目录里的 lwjgl.jar 换成 lwjgl3 的 jar 不就行了？实测下来，这样做的结果是启动器直接报NoClassDefFoundError，或者进游戏后一片漆黑。

原因在于两个版本的 API 设计哲学完全不同。LWJGL2 是一个"大而全"的门面类风格：窗口、输入、GL 调用几乎都挂在Display、Keyboard、Mouse、GL11这几个静态类上，全局状态满天飞。LWJGL3 则把职责拆开了：窗口和输入交给 GLFW，GL 调用虽然还在GL11这类类里，但方法签名、返回值、缓冲区管理方式都改了，尤其是那些需要传IntBuffer的地方，LWJGL3 大量改成了直接返回 int 的便捷重载，同时保留了带n前缀的 native 版本。

举个最典型的例子。老代码里生成纹理 ID 一般这么写：

IntBuffer buf = BufferUtils.createIntBuffer(1); GL11.glGenTextures(buf); int texId = buf.get(0);

而 LWJGL3 里直接有返回值版本：

int texId = GL11.glGenTextures();

虽然 LWJGL3 也保留了带 buffer 的重载，但如果你依赖的是Display.create()、Keyboard.isKeyDown()、Mouse.getDX()这些类，它们在新库里根本不存在。整个游戏主循环、输入处理、窗口创建，全部要重写。这就是为什么单纯换 jar 行不通。

1.2 为什么不能推翻重写，只能"偷梁换柱"

理论上最干净的做法是把游戏客户端源码拿过来，把 LWJGL2 相关的调用全部改写成 LWJGL3 风格。但 1.7.10 的生态里，模组不是通过源码接入的，而是编译好的 class 文件。一个大型整合包动辄两三百个模组，其中相当一部分直接调用了GL11、Keyboard、Mouse，甚至直接操作Display。你改了游戏本体，模组照样调老 API，一样崩。

所以唯一可行的路线是：在类加载阶段做字节码层面的调用重定向，把模组和游戏里对旧 API 的引用，悄悄指向一套新写的兼容实现。模组自己浑然不觉，它以为自己在调 LWJGL2，实际上落到 LWJGL3 的实现上。这个思路决定了 LWJGL3ify 的整个技术形态，也是它区别于"重写客户端"类项目的核心。

2. LWJGL2 到 LWJGL3 之间的三层断层

真正动手之前，得把断层分清楚。我把它们归成三层：类结构断层、语义断层、native 断层。三层难度递增，处理方式也完全不同。

2.1 类结构断层：那些凭空消失的类

第一层最直观。LWJGL2 里有一批类在 LWJGL3 中彻底不存在：

• org.lwjgl.opengl.Display—— 窗口创建、尺寸、标题、垂直同步、全屏切换，全在这
• org.lwjgl.opengl.DisplayMode—— 分辨率与刷新率描述
• org.lwjgl.input.Keyboard/org.lwjgl.input.Mouse—— 键盘鼠标状态轮询
• org.lwjgl.input.Controllers—— 手柄
• org.lwjgl.opengl.GLContext—— 上下文能力查询
• org.lwjgl.openal.AL—— 音频设备与上下文初始化

这些类的消失不是随意删减，而是职责被 GLFW 接管了。问题是，模组代码里写死了Display.isCloseRequested()、Keyboard.getEventKey()这样的调用，字节码里就是一条invokestatic指令指向那个类。类不存在，加载就失败。

LWJGL3ify 的解法是自己实现一套同名的兼容类，把这些调用接住，内部再转成 GLFW 的调用。所以你会在项目的 jar 里看到一整套仿 LWJGL2 的类，名字和老的一模一样，但内部逻辑是新的。这是一种很典型的适配器模式，只是发生在字节码层而不是源码层。

2.2 语义断层：方法还在，行为变了

第二层更隐蔽。有些方法名字一样、签名一样，但行为已经不同了。这类问题不会在加载期报错，只会在运行期以诡异的方式暴露出来。

一个典型例子是 OpenGL 上下文与线程的关系。LWJGL2 的Display.create()内部会把当前线程和 GL 上下文绑定，之后所有 GL 调用都必须在那个线程上执行。GLFW 的模型类似但更严格：glfwMakeContextCurrent必须在创建窗口的线程调用，且 GLFW 的大部分函数都不是线程安全的。如果某个模组在后台线程里偷偷调了一次GL11.glGenTextures，LWJGL2 时代可能"碰巧能跑"，LWJGL3 下就可能直接崩或者静默失败。

再比如缓冲区交换与垂直同步。老代码调Display.update()完成一帧，内部实现是glfwSwapBuffers加事件轮询。但事件轮询的时机变了：LWJGL2 的Display.update()会顺带处理输入事件队列，GLFW 则要求你显式调glfwPollEvents。如果兼容层没处理好这个顺序，表现就是输入延迟一帧、或者按键丢失。

还有全屏模式。LWJGL2 的Display.setFullscreen(true)走的是真正的独占全屏，会切换显示模式；GLFW 在现代系统上更推荐无边框窗口全屏。两者在 Alt+Tab 行为、多显示器处理、HDR 支持上完全不同。这块如果处理粗糙，用户会明显感知到"切出去回不来了"。

2.3 native 断层：打包与加载的坑

第三层是最容易被低估的。LWJGL3 的 native 库组织和 LWJGL2 完全不同。老版本是把.dll、.so、.dylib塞进 jar 里，运行时解压到临时目录再System.load。新版本则是把 native 作为独立的 artifact 发布，通过 Maven 坐标按平台区分，比如lwjgl-opengl的 natives 会有natives-windows、natives-linux、natives-macos-arm64等多个 classifier。

这意味着启动器必须正确解析并下载对应平台的 native 包。稍微配错一个 classifier，就会出现UnsatisfiedLinkError。更麻烦的是，一个完整的 LWJGL3 运行环境需要至少七八个 native 模块：lwjgl（核心）、lwjgl-glfw、lwjgl-opengl、lwjgl-openal、lwjgl-stb（图像加载）、lwjgl-tinyfd（文件对话框）、lwjgl-jemalloc（内存分配器）。少一个就在对应功能上炸。

LWJGL3ify 在这方面做了大量打包工作，把这一整套按平台整理好，并且处理了和旧版 native 共存的冲突问题——老版本的 jar 还躺在库里，如果 classpath 顺序不对，加载到的可能还是旧 native。

3. LWJGL3ify 的骨架：重映射与兼容外壳怎么配合

把三层断层摸清楚之后，再看这个项目的实现结构就顺了。它大致由三块组成：一个负责改字节码的 coremod、一组仿 LWJGL2 的兼容类、一套打包好的 LWJGL3 运行时。三者配合的方式值得拆开讲讲，因为这套思路在做其他老版本适配时也能借鉴。

3.1 ASM 重映射：在类加载那一刻动手

Minecraft 1.7.10 的 Forge 提供了一套 coremod 机制，允许在类被加载进 JVM 之前拦截其字节码。LWJGL3ify 正是挂在这个钩子上。

具体流程是：游戏启动时，Forge 的IFMLLoadingPlugin被调用，项目在这里注册一个IClassTransformer。之后每当有类被加载，转换器就会检查它的字节码里有没有对旧 LWJGL 类的引用。如果有，就通过 ASM 修改常量池中的类名和方法描述符，把org.lwjgl.opengl.Display改成项目自己的兼容实现路径，或者把某些方法调用改成等价的新调用。

这里有个关键取舍：改类名还是改调用。如果只是把Display指向同名的兼容类，那常量池里的类名其实不用变，只要保证 classpath 上先加载到兼容类就行。但Keyboard、Mouse这些类的包名是org.lwjgl.input，如果项目和真正的 LWJGL3 库同时存在，就可能冲突。所以实际做法往往是给兼容类换一个独立的包名，然后用 ASM 把所有引用重定向过去。

转换器需要处理的类数量相当可观。除了游戏本体的几百个类，还要扫描所有模组的 class。这里性能是个隐患：如果每个类都做全量字节码扫描，启动时间会明显变长。实际实现里一般会先做一次快速字符串匹配，确认字节码里含有目标包名的字样，再走完整的 ASM 解析。这个优化很关键，实测能把启动时间从几十秒压回正常范围。

提示：如果你自己在写类似的转换器，务必在transform方法入口做一次new String(classBytes, StandardCharsets.ISO_8859_1).contains("org/lwjgl/")之类的粗筛。纯 ASM 解析几百 MB 的 class 数据，代价远超你的想象。

3.2 兼容外壳：把 GLFW 包装成老 API 的样子

重映射只解决了"调用能不能找到"的问题，真正干活的是兼容类。这块是整个项目里工作量最大的部分，因为要尽可能还原 LWJGL2 的行为语义。

以Display为例，兼容实现需要维护这些状态：当前窗口句柄、窗口尺寸与 framebuffer 尺寸（HiDPI 下两者不同）、是否全屏、垂直同步开关、关闭请求标志。Display.create()内部要依次调glfwInit、设置窗口提示（版本、profile、采样数）、glfwCreateWindow、glfwMakeContextCurrent、GL.createCapabilities。Display.update()要调glfwSwapBuffers和glfwPollEvents。Display.isCloseRequested()则要读 GLFW 的窗口关闭标志。

输入部分的处理更细。LWJGL2 的Keyboard采用的是事件队列 + 状态数组双模型：你既可以轮询isKeyDown，也可以用next()逐个消费事件。GLFW 只提供回调：按键按下时触发GLFWKeyCallback。要把回调模型转成队列模型，就得在回调里把事件塞进一个ConcurrentLinkedQueue，然后在next()里弹出。这里要注意线程问题——GLFW 的回调是在主线程的事件轮询中触发的，但如果兼容层允许其他线程调用next()，队列就必须是线程安全的。

音频这块同样要包。旧代码调AL.create()初始化，然后AL10.alGenSources()之类。LWJGL3 的 OpenAL 绑定保留了AL10、AL11这些类，但设备枚举和上下文创建的 API 变了，需要一层桥接。好在音频的问题通常只影响声音，不影响游戏能不能跑，优先级可以放低。

3.3 一个容易被忽略的细节：GL 能力查询

老代码里经常出现这种写法：

if (GLContext.getCapabilities().GL_ARB_vertex_buffer_object) { // 用 VBO } else { // 回退到显示列表 }

GLContext.getCapabilities()返回的是一个巨大的能力对象，字段名对应各个 OpenGL 扩展。LWJGL3 里对应的是GLCapabilities，通过GL.createCapabilities()获取，字段命名规则也变了（去掉了GL_前缀）。

兼容层必须把这两套字段映射起来。麻烦在于，老代码可能访问任何字段，而 LWJGL3 的GLCapabilities并不包含所有老字段——有些扩展在新版本里被合并进核心了，字段直接消失。这种情况下兼容类只能硬编码返回 true 或 false，判断依据是该扩展是否已成为 OpenGL 3.2+ 的核心功能。这个映射表得一个个手工核对，属于典型的脏活累活，但漏一个就可能导致某个模组的渲染路径走错分支，出现奇怪的花屏。

4. 把 LWJGL3ify 装进 1.7.10 环境的完整路径

聊完原理，说说怎么真正跑起来。这一节的操作基于我实际配置过的流程，具体版本号以项目发布页的说明为准，因为这类项目迭代较快，参数可能会有调整。

4.1 前置条件核查

动手前先确认三件事，任何一件不满足都会让后面的步骤白费。

第一是 Java 版本。LWJGL3ify 面向的是现代 JVM，一般要求 Java 17 或更高。这带来一个连锁反应：Java 17 的模块系统默认禁止反射访问 JDK 内部 API，而 1.7.10 的 Forge 和大量模组严重依赖反射。所以启动参数里必须补上一批--add-opens和--add-exports。

第二是 Forge 版本。需要 1.7.10 的最终版 Forge，早期版本缺少某些 coremod 钩子。同时要确认你的启动器能正确传入 JVM 参数，某些老启动器会把参数吞掉。

第三是清理旧 native。如果之前跑过原版 1.7.10，libraries目录里会残留 LWJGL2 的 jar 和 native。这些必须处理掉，否则 classpath 上可能出现新旧混载。

4.2 安装步骤

整体流程可以分成四步，我按顺序列出来：

1. 准备一个干净的 1.7.10 + Forge 实例。不要在已有的整合包里直接改，先复制一份出来做实验。整合包里的模组冲突排查会把你拖进无尽的泥潭。

2. 放入 LWJGL3ify 的模组文件。项目通常以 coremod 形式发布，需要放到mods目录或者coremods目录，具体位置看发布说明。有的版本还会附带一个配置文件，用来开关某些兼容行为。

3. 替换 LWJGL 运行时。这一步是核心。项目会提供一套 LWJGL3 的 jar 和 native，需要覆盖到实例的libraries目录对应位置，或者通过启动器的依赖管理机制注入。手工操作时要注意目录结构必须和 Maven 坐标一致，否则启动器找不到。

4. 配置 JVM 参数。这是最容易出错的一步。典型的参数形态大概是这样：

java \ -Xmx4G -Xms4G \ --add-opens java.base/java.lang=ALL-UNNAMED \ --add-opens java.base/java.lang.reflect=ALL-UNNAMED \ --add-opens java.base/java.util=ALL-UNNAMED \ --add-opens java.base/java.nio=ALL-UNNAMED \ --add-opens java.base/sun.nio.ch=ALL-UNNAMED \ -Djava.library.path=<指向 lwjgl3 native 目录> \ -Dorg.lwjgl.librarypath=<同上> \ -jar forge-launcher.jar

--add-opens这一串不是随便写的，每一条都对应一类反射访问。java.lang和java.lang.reflect是 Forge 的事件总线在用，java.nio和sun.nio.ch是 LWJGL 的缓冲区直接内存访问在用。少一条，启动日志里就会出现InaccessibleObjectException。

java.library.path和org.lwjgl.librarypath两个都要设，因为不同的加载路径会读不同的属性。这一点文档里往往写得含糊，实测下来两个都配上最稳。

4.3 首次启动要盯什么

第一次启动别急着进世界，先看日志。有几个关键点必须在日志里确认：

• LWJGL 版本号是否显示为 3.x。如果还是 2.9.x，说明运行时没替换成功。
• GLFW 初始化是否成功，有没有报显示器枚举失败。
• OpenGL 上下文版本是否达到 3.2 以上。低于这个值，说明显卡驱动走了兼容模式，后面会很卡。
• 有没有出现ClassNotFoundException指向org.lwjgl.input.*。有的话说明重映射没生效，检查 coremod 是否被正确加载。

进游戏后先做三个动作验证：按 F11 切换全屏再切回来、拖动窗口改变大小、在输入框里打几个中文字。这三个动作分别验证全屏状态管理、framebuffer 尺寸响应、输入法桥接，是最容易暴露兼容层缺陷的地方。

4.4 关于启动参数的一个经验

-Xmx和-Xms设成一样大，这在现代 JVM 上依然是个好习惯，能避免运行期堆扩容带来的卡顿。但要注意，LWJGL3 的 native 内存不走堆，jemalloc会单独分配。所以如果你的整合包模组多、贴图多，光调大-Xmx没用，还得关注 native 内存。某些启动器支持-XX:MaxDirectMemorySize，可以适当调高。

另外，-Dorg.lwjgl.util.Debug=true这个参数在排查阶段非常有用，它会把 GLFW 和 OpenGL 的详细调用日志打出来。但它会显著拖慢启动和运行，稳定之后记得去掉。

5. 几类高频故障的排查链路

下面这几类问题我在不同机器上反复遇到过，把它们按"现象→定位→修复"的链路写一遍，方便你对照排查。

5.1 启动即崩：UnsatisfiedLinkError 的定位方法

现象是启动器日志末尾出现java.lang.UnsatisfiedLinkError: Failed to locate library: liblwjgl.so（Linux）或者glfw.dll（Windows）。

第一步看报错里提到的库名。如果是lwjgl核心库缺失，说明 native 包根本没下载下来，多半是 classifier 配错了。Apple Silicon 上要的是natives-macos-arm64，配成natives-macos就会找不到。如果是glfw缺失，说明只下了核心库没下 GLFW 模块，这两个是独立的 artifact。

第二步验证 native 是否真的被解压到磁盘。可以临时加-Djava.library.path指向一个空目录，看报错里的搜索路径列表。有时候文件在，但路径里的反斜杠或空格转义有问题，Windows 上尤其常见——路径带空格时如果没加引号，会被截断。

第三步检查 jar 冲突。用-verbose:class启动，搜索org.lwjgl，看加载到的类来自哪个 jar。如果同时出现 lwjgl2 和 lwjgl3 的 jar，说明旧的没清理干净。

5.2 能进游戏但黑屏：上下文版本不匹配

现象是窗口正常打开、标题正常、但画面全黑，日志里没有异常。

这类问题九成出在 OpenGL 上下文版本上。LWJGL3 默认可能请求 3.2 core profile，而某些老模组依赖 compatibility profile 的固定管线功能（比如glBegin/glEnd、显示列表）。core profile 下这些函数根本不存在，调用会静默失败，结果就是什么都不画。

解决方向是让兼容层请求 compatibility profile。这通常通过项目的配置文件控制，或者在窗口创建提示里设置GLFW_OPENGL_PROFILE为GLFW_OPENGL_ANY_PROFILE。但要注意，macOS 上不支持高于 2.1 的 compatibility profile，所以在 Mac 上只能走 core profile，那些依赖固定管线的模组就是跑不了。这是个硬性限制，不是配置能绕过去的。

还有一种黑屏是 framebuffer 尺寸算错了。HiDPI 屏上窗口逻辑尺寸是 1920x1080，但 framebuffer 实际是 3840x2160。如果 viewport 按逻辑尺寸设置，画面只占左下角四分之一。检查方法是在日志里对比glfwGetWindowSize和glfwGetFramebufferSize的返回值。

5.3 输入失灵：事件队列的时序问题

现象是按键没反应、或者按一下触发多次、或者鼠标移动方向和实际相反。

按键重复触发通常是因为事件队列被重复消费。兼容层里的队列如果在每帧开头清空、又在next()里重复读取，就会出现这个问题。排查方法是临时把队列长度打进日志，看每帧的事件数量是否异常。

鼠标方向相反则和坐标原点有关。LWJGL2 的鼠标 Y 轴向上为正，GLFW 的屏幕坐标 Y 轴向下为正。兼容层如果忘了翻转，就会出现上下颠倒。这类问题在菜单界面不明显，一进游戏转视角立刻察觉。

输入法问题更麻烦一些。GLFW 提供了glfwSetCharCallback来接收字符输入，但中文输入法的候选框定位依赖glfwSetPreeditCallback（或者 IME 相关接口）。如果兼容层只处理了字符回调没处理预编辑回调，表现就是能打出字但看不到候选框，或者候选框固定在窗口左上角。这个问题的修复需要在兼容层里补上 IME 事件的转发，工作量不小。

5.4 音频无声或爆音

现象是游戏能跑但完全没声音，或者声音断断续续带爆音。

先查设备枚举。LWJGL3 的 OpenAL 初始化需要显式指定设备，如果设备名字符串匹配不上（比如系统语言导致的设备名差异），就会 fallback 到 null 设备，表现为静默。日志里搜ALC关键字，看有没有Failed to open device。

爆音一般是缓冲区大小配置不当。OpenAL 的 source 需要绑定 buffer，如果兼容层把 buffer 设得太小，或者采样率不匹配，就会出现断续。这个参数在配置文件里通常可以调，把 buffer 数量从默认值往上加一档试试。

6. 和渲染类模组的共存边界

这一节可能是最多人关心的：装了 LWJGL3ify 之后，OptiFine、光影、各种渲染优化模组还能不能用。

6.1 冲突的根源在于都动了同一层

渲染类模组的做法通常是替换或 hook 游戏的渲染管线，而 LWJGL3ify 动的是渲染管线的底座。两者在调用链上是有交集的，冲突几乎不可避免。

以 OptiFine 为例，它会 hook 大量GL11调用，自己管理 VBO、FBO、shader 程序。这些 hook 是针对 LWJGL2 的类和方法签名写的，重映射之后，hook 点可能对不上，轻则功能失效，重则直接崩。而且 OptiFine 有自己的 GL 能力检测逻辑，它读GLContext.getCapabilities()的字段，如果兼容层的映射表缺字段，它可能走进错误的分支。

光影模组的冲突更直接，它们大量使用自定义 shader 和 FBO 链，对 GL 状态机的假设非常严格。LWJGL3 在某些状态默认值上和 LWJGL2 有细微差异（比如 VAO 的默认绑定状态），这些差异在普通渲染里看不出来，在复杂 shader 管线里就会放大成画面异常。

6.2 实际可行的组合策略

根据我这边的测试，比较稳的搭配原则是：要么用 LWJGL3ify 走现代路线，要么用传统渲染优化模组走老路线，不要混。

如果目标是让老整合包在新机器上跑起来，优先选 LWJGL3ify，然后放弃那些深度 hook 渲染的模组。整合包里如果有渲染优化类的模组，先禁用，进游戏看帧率。现代硬件上，LWJGL3 本身的效率提升往往能补上失去优化模组的损失，尤其是在 Apple Silicon 这类原生 arm64 环境下，差距可能是数量级的。

如果目标是追求极致画质和光影效果，那 LWJGL3ify 目前不是好选择。这类需求建议留在传统路线，或者考虑升级到更新的游戏版本——新版本身就跑在现代化的渲染底座上，没必要在老版本上硬拗。

有一类模组是可以共存的：纯逻辑类、UI 类、内容扩展类。它们不碰 GL 调用，只调用游戏的高层 API，重映射对它们完全透明。判断方法很简单，看模组的依赖里有没有直接引用org.lwjgl。有就警惕，没有基本安全。

6.3 一个折中的观察

我注意到一个有意思的现象：随着 LWJGL3ify 这类项目成熟，一些原本只做渲染优化的模组作者开始把功能拆分开，把纯逻辑部分（比如剔除算法、区块加载优化）和渲染部分解耦。前者的兼容性好得多，可以在新底座上跑；后者则逐渐被底座本身的能力替代。

这个趋势对老版本生态是好事。它意味着"现代化"不再是一个全有或全无的选择，而是可以按模块逐步推进。你完全可以先用 LWJGL3ify 解决启动和输入问题，保留内容类模组，暂时放弃光影，等生态跟上再补。

最后分享一个实操中的小技巧：在切换底座前后，用同一个存档、同一个视角、同一个/tp坐标截两张图对比。不要只看帧率数字，因为新旧底座的垂直同步策略不同，帧率数字可能失真。看画面细节——远处方块的边缘是否锯齿、天空渐变有没有色带、粒子效果的透明度是否正确——这些才是判断渲染路径有没有走对的可靠依据。我自己就靠这招发现过一次兼容层把 sRGB 转换漏掉的问题，表现是整体画面偏亮一档，帧率完全正常，光看数字根本发现不了。