Java
这件事让我想起一个亲身经历。我之前搭建了一个基于 Gitea 的 Git 仓库托管平台，顺便用他们新推出的 Act Runner 替代了 Drone CI。Act Runner 的目标是实现一个自托管的、完全兼容 GitHub Actions 配置文件的 CI/CD 工具。作为一个热衷尝鲜、充满活力的准程序员，我的原则是能用最新的就不用旧的，连开发环境都选用了 Fedora 和 Arch 这类前沿系统。当 Act Runner 更新时，我自然第一时间升级了它。巧合的是，在更新后我推送了一次代码，工作流中最后一个 Job 是通过 SCP 上传文件，但无论如何都无法正常运行，总是提示找不到要打包的文件。我花了整整一个下午排查问题，最终发现回滚到旧版本的 Act Runner 后，一切又恢复正常了。虽然这个问题可能与 Act Runner 的更新关系不大，但它确实让我意识到：追求最新版本和实际项目落地之间可能存在矛盾。一个大型项目从规划到落地再到维护直至生命周期结束，可能需要数年时间，而程序依赖的版本可能早已发生变化。此外，开发团队积累的经验未必适用于新版本。最简单的方案往往是维持现状。比如几个月前，我为了学习 Hadoop 安装了最新版本，却发现只有 JDK 1.8 才能保证 HDFS 正常运行，换成 JDK 17 就会出现各种问题（当然，我不是专业的
Java 开发者，也许是我哪里操作失误了）。再比如 LuaJIT，这是一款被广泛使用且性能优越的工具，但它目前似乎只支持 Lua 5.1 的语法。如果为了性能选择 LuaJIT，那也就意味着只能局限于 Lua 5.1 的语法规范了。这种情况下，追求新技术可能会带来额外的成本和限制，值得我们在决策时仔细权衡。
