WeKan Multiverse 路线图：从 Meteor 到跨 CPU、跨 OS、跨浏览器、跨数据库的多宇宙探索-酒店常州论坛

WeKan Multiverse 路线图：从 Meteor 到跨 CPU、跨 OS、跨浏览器、跨数据库的多宇宙探索

【免费下载链接】wekanThe Open Source kanban, built with Meteor. GitHub issues/PRs are only for FLOSS Developers, not for support, support is at https://wekan.fi/commercial-support/ . PR source translation to imports/i18n/data/en.i18n.json, other translations at https://app.transifex.com/wekan/wekan项目地址: https://gitcode.com/GitHub_Trending/we/wekan

本文以仓库内设计文档 docs/Design/Multiverse/WeKan-Multiverse-Roadmap.md 为主线，系统解读 WeKan 的"Multiverse（多宇宙）"演进路线：如何在 s390x 大型机、AmigaOS、FreeDOS 等非主流 CPU/操作系统上运行看板，如何用 QEMU 解决 AVX 指令集缺失问题，以及用 Redbean、PHP、Gambas、Haxe、FreePascal 等数十个原型验证"换一种技术栈是否可行"。读完你可以掌握 WeKan 的跨平台兼容矩阵、无 JavaScript/无 WebSocket 浏览器的应对策略，以及维护者 xet7 对 Web 框架的九大技术期望。

什么是 WeKan Multiverse

WeKan 是一个基于 Meteor 的开源看板（Kanban）应用。所谓 "Multiverse"（多宇宙），是 WeKan 维护者 xet7（Lauri Ojansivu）对项目长期技术路线的一种概括性设想：不把所有鸡蛋放在一套技术栈里，而是用大量原型（prototype）去试探"换一种语言、换一种数据库、换一种前端，能否让 WeKan 生态覆盖更多 CPU、更多操作系统、更多浏览器"。

该路线图的核心论点来自 FUTURE.md 中对平台支持的总体判断：平台支持经常变化，因为依赖众多、Node.js 在某些 CPU/OS 上会段错误（segfault）、某些平台存在构建错误；因此路线图的长期任务是"更新所有现有平台，并增加更多平台"。Multiverse 文档则进一步把这句口号展开为一张可执行的技术地图：哪些技术天生跨平台、哪些技术被平台卡死、用哪些原型可以逐步验证替代方案。

AVX 指令集与 QEMU 模拟：CPU 层面的第一道坎

Multiverse 文档开篇即讨论 AVX（Advanced Vector Extensions）。这是现代 x86_64 CPU 上的一套 SIMD 向量指令集，而它对 WeKan 生态的影响非常实际：

Bun JavaScript 引擎要求 CPU 支持 AVX；
MongoDB 5.x 及更新版本在 x86_64 上强制要求 AVX。

如果 CPU 没有 AVX，WeKan 的 Snap Candidate 版本（基于 Meteor 2）现在采用qemu-user 运行 MongoDB，借助 QEMU 的 AVX 支持完成模拟执行。这一能力自WeKan v7.93（2025-07-18）起加入，详见 CHANGELOG.md。

在仓库源码中，可以找到这一策略的完整工程化实现：

snapcraft.yaml 的mongo50部分明确注释："AVX: MongoDB 5.0 and later REQUIRE it on x86_64. migration-control runs this reader throughbin/cpu-execwithx86_64=avx, the same way it runs mongod 7, so a CPU without AVX reads the database under qemu-user emulation - slow, and a one-time read."（慢，但只是一次性迁移读取）。
同一文件中的migratemongopart（snapcraft.yaml）从 wekan/migratemongo 仓库取得 MongoDB 3.2 的 x86_64 二进制及其AVX QEMU 包装（avx/目录），用于在一次性迁移中读取旧版 3.2 数据，仅限 amd64。
releases/build-release-bundle.sh 说明：构建 bundle 时会按架构选择随包分发的 qemu-user 二进制（amd64 用qemu-x86_64-static，arm64 用qemu-aarch64-static），并在缺少时给出apt install qemu-user-static的提示。
releases/build-bundle-armhf.sh 同样注明：armhf 的 WeKan snap 打包了qemu-x86_64-static，用来在 armhf 上运行 MongoDB 的 amd64 二进制。

这套"真架构跑不了，就用 qemu-user 模拟跑"的思路，是理解整个 Multiverse 路线图的第一把钥匙：它不是追求一次到位，而是让旧硬件、旧系统也能先跑起来。

跨平台支持矩阵：什么能跑，什么不能跑

Multiverse 文档给出了一张非常直白的兼容性清单。以 s390x（IBM Z 大型机使用的 64 位架构）为分水岭：

在 s390x 上不工作

Bun JavaScript 引擎；
Deno JavaScript 引擎（其 Rust ring 加密依赖不支持 s390x，见 docs/Platforms/FOSS/HW/s390x.md）；
Lazarus IDE及其所依赖的FreePascal 语言（FreePascal 尚未支持 s390x，参见 docs/Platforms/FOSS/HW/s390x.md 中引用的 ZSeries 支持现状）；
TigerBeetle 数据库。

在 s390x 上工作

编程语言：Node.js（不是 Deno 或 Bun）、C89（xet7 曾把 Darkest Hour 移植到 30+ CPU/OS）、PHP、Go、Tcl/Tk；
Web 框架：V 的 veb、Gambas、Python Py4Web、Ruby on Rails、WeKan Studio；
GUI：BBC Basic、Godot、Redot、HaxeUI。

在 AmigaOS 3.x/4.x、MorphOS、AROS、Win/Mac/Linux 上工作

FreePascal 的 wami 原型（Web 框架方向）。

从 docs/Platforms/FOSS/HW/s390x.md 可以了解更多 s390x 的实战细节：xet7 通过 IBM LinuxOne Community Cloud 获得大型机访问权限（2023-09 起配额为 2 台 VM，各 8 GB 内存、200 GB 磁盘、4 CPU）；s390x 的 MongoDB 可以安装 Canonical 的juju-dbsnap（含多架构 MongoDB），并需在.bashrc中手工配置LD_LIBRARY_PATH与PATH指向/snap/juju-db/139/bin；旧的 RHEL 7 上则可以直接下载 MongoDB v4.x Community Server 的 s390x rpm 包。

原型策略：多试错，找出真正可行的方案

Multiverse 的工程方法论浓缩为一句话："Try building many prototypes, see what works"（多建原型，看哪个可行），即经典的 "throw things at the wall and see what sticks"（往墙上扔东西，看哪个粘得住）。

这句话落实到 WeKan 仓库中，就是你可以在 docs/Design/Multiverse 目录下看到的一系列姊妹文档：Alternative-Architectures.md、FreePascal.md、Go.md、Haxe.md，它们分别对应"换一套架构""换一门语言"的独立探索分支。每一个原型都不要求功能完整——只要验证"这条路是否走得通"即可。

对 Web 框架的九大期望

Multiverse 文档专门列出"Wishes to all web frameworks"（对所有 Web 框架的期望），这既是 WeKan 对未来技术选型的评判标准，也是任何想要替代 Meteor 的框架必须回答的问题：

可升级性：提供完整的升级文档（包含所有必需步骤），或者提供一个自动完成升级的脚本；
模块化可拆分：框架的部件可以作为独立包使用，例如把 OAuth2、Gmail 等认证能力拆出来单独引用；
可禁用 WebSocket：因为部分企业网络不允许 WebSocket，需要提供非 WebSocket 的实时方案；
支持纯服务端渲染（SSR）且前端无 JavaScript：可以同时支持"有 JS"和"无 JS"两种前端模式（ufront 曾做到过），并保留无 JavaScript 的 HTML 版本；
会话持久化到数据库：以支持 round-robin 多实例部署；
无构建步骤：文件保持原有目录结构（按"功能名/功能子部件"组织），只在需要的页面引入对应文件，缓存依赖以支持离线编码，且不做代码压缩（uglify）；xet7 提到自己把所有分支合并到单一 main 分支，因为分支间合并耗时太多；
不使用 eslint、prettier 等 linter：因为 linter 之间对语法意见不一致，而目标应是"用最小改动修一个 bug 或加一个功能"，而不是让大多数提交都在修语法；
长期运行不卡顿：参考 CGI 模型，每请求运行完释放全部内存，避免运行一周后变慢失响应；
同时支持 On-Premise（本地部署）与 MultiCloud（多云），且保持 MIT 等宽松许可。

其中第 3 点（可禁用 WebSocket）与当前仓库的 start-wekan.sh 形成直接对照：WeKan 启动脚本中METEOR_REACTIVITY_ORDER可在changeStreams,oplog,polling与纯polling之间切换，DDP_TRANSPORT=sockjs表明 bundle 只携带 sockjs 传输层；当数据库不可用 Change Streams 时，可以退回polling（轮询）模式，这正是"不依赖 WebSocket/实时订阅也能工作"的现有实现证据。

实时 Web 框架清单

Multiverse 正在追踪的实时（realtime）Web 框架只有两个：

Meteor：WeKan 当前的技术底座，整个仓库的client/、server/、imports/、models/目录结构都是标准的 Meteor 应用布局，依赖 MongoDB 复制集的 Change Streams / oplog 实现实时刷新；
Helene：一个面向 Node.js 和 Bun 的轻量级实时 Web 框架（由社区发起，文档中标注为"Others?"的候选）。

清单保持开放，随时欢迎新候选加入验证。

浏览器多宇宙：从 Ladybird 到 FreeDOS Dillo

Multiverse 路线图中有一个有趣但极其务实的部分——浏览器兼容分层：

为"治疗"而开发的浏览器：Gosub、Ladybird；
支持 JavaScript 的浏览器：用 JS 实现拖拽等特性，并隐藏无 JS 浏览器用不到的 UI 元素；
不支持 WebSocket 的浏览器：用 long poll 长轮询，或者干脆不做实时更新、要求页面刷新，面向内网禁止 WebSocket 的场景；
不支持 JavaScript 的浏览器（或无 JS 且因安全原因禁用 JS 的浏览器）：Netsurf（覆盖 RISC OS、ReactOS、Redox OS、Haiku、Linux、Windows、Amiga、Atari 等）、Amiga 的 AWeb 与 iBrowse、FreeDOS 的 Dillo 与 Arachne、文本浏览器 Lynx/Links/w3m、以及 Netscape/IE 等所有 OS/CPU 上的老浏览器；
可编程浏览器：Nyxt。

文档强调了一个重要推论：Wekan 的多浏览器策略是"支持"而不是"放弃"——对于无 JS 浏览器，可以采用 HTML4、图片、imagemap 等降级方案保证页面可读；对于不支持 WebSocket 的浏览器，则退回到轮询模式。这正是上文中 start-wekan.sh 轮询模式存在的意义。

文档还展示了一张"Multiverse WeKan"截图（manybrowser.png），直观呈现 WeKan 在 Windows、Linux 以及新旧多代浏览器中的渲染一致性：

数据库多宇宙：SQLite、PostgreSQL 与本地优先

Multiverse 对未来数据库的设想包括：

SQLite；
PostgreSQL；
数据库之间的迁移；
同时使用多个数据库；
离线 / 本地优先（Local-First）。

在 snapcraft.yaml 中可以看到这条路线的现实投影：注释明确写道 "arm64 uses MongoDB 7, other arches use FerretDB v1"——即在非 amd64/arm64 架构上，WeKan snap 直接使用FerretDB（PostgreSQL 的 MongoDB 协议代理）作为数据库后端，而非原生 MongoDB。这与 Multiverse 文档中"支持更多数据库""在多数据库之间迁移"的设想一脉相承：仓库根目录同时提供了 docker-compose-ferretdb-v1-postgresql.yml、docker-compose-ferretdb-v1-mariadb.yml、docker-compose-ferretdb-v1-mysql.yml、docker-compose-ferretdb-v2-postgresql.yml 以及 docker-compose-mongodb-v7.yml，正是"一库多用、按需迁移"的落地形态。

Multiverse 文档还记录了一个真实的 SQLite 迁移验证案例：当看板数量很大时，希望按看板名称首字符分组计数。维护者用 SQLite 实现了这一查询（MongoDB aggregate 当时没有找到等价写法，SQLite 立即返回结果）：

SELECT _id, substr(title,1,1), COUNT(*), type from boards WHERE type=:type GROUP BY substr(title,1,1) ORDER BY substr(title,1,1) ASC;

文档还提到：该查询在 Netsurf 浏览器上可以正常显示 emoji 与 UTF-8，FreeDOS Dillo 上能否显示仍在 TODO 中；同样的分组逻辑也被移植到了 PHP 原型的allboardschar.php页面。这说明 Multiverse 的数据层探索是"带着真实功能需求"进行的，而不是纸上谈兵。

图形与编程语言替代方案

图形层

Raphael JS：通过 VML 和 SVG 同时支持大量老浏览器；
或者干脆只用 HTML4、图片、imagemap，以保证与无 JavaScript 浏览器兼容。

编程语言与编译替代

Transpiler（源到源编译器）路线：Haxe（配合 HaxeUI 的 GUI/WebUI 与 TUI）、Wax、Nim、V；甚至设想把 UI 在 HaxeUI XML、HTML4、HTML5、Gopher、Gemini、Lazarus、Gambas、Godot、MUI/ZUI（Amiga/AROS）之间互相转换；
C89：用于 30+ OS/CPU 的嵌入式 Web 服务器与小程序；
Pascal + TRSE：面向复古平台；
同时强调尽量规避奇特的 NPM 包，以降低供应链与性能风险。

基准测试

Multiverse 在语言选型上坚持"用数据说话"，列出的基准来源包括：WeKan 维护的hx原型仓库中的 webserver 性能对比、Meteor 论坛的 Meteor 3 与 Meteor 2 性能测试、以及 TechEmpower Framework Benchmarks 的跨框架横向对比。

原型清单：十二个技术路线的进展盘点

Multiverse 文档逐一记录了各原型仓库的状态，这是理解"多宇宙"最直接的部分：

Redbean（当前主攻方向）

基于Cosmopolitan（docs/Platforms/FOSS/HW/s390x.md 有详尽说明），redbean.com单个 amd64 二进制无需修改即可在 Win/Mac/Linux/BSD/BIOS 上运行；
最小看板拖拽示例使用HTMX做 UI，数据存SQLite；
Petclinic fork 通过Blink（x86_64 模拟器，类似 qemu）在 s390x 上运行，相关细节见 docs/Platforms/FOSS/HW/s390x.md#petclinic-s390x；
xet7 当前的主力工作对象，对应 WeKan Studio 原型。

PHP

部分页面兼容所有浏览器；SQLite 按首字符列出所有看板；对新版 MongoDB 的驱动测试；支持拖拽上传文件（对应 issue #2936 的即将上线功能）；支持 RTL 从右到左布局；
尚未完成：登录、移动卡片。

Gambas

已实现：登录、下拉菜单结构、SQLite 数据库；
尚未完成：显示看板；且登录页依赖 JavaScript，在 Netsurf 中无法工作。

Meteor SSR

仅做服务端渲染，前端彻底移除 JavaScript；
目前只是测试页面，没有实际功能——这是"无 JS 前端"路线的最小可行性验证。

Node.js 20、Bun 和 Deno

main.js可向多种数据库发查询：旧版 MongoDB 3.2.x（配合sudo snap install wekan）、新版 MongoDB 6.x、FerretDB 代理到 PostgreSQL、FerretDB 代理到 SQLite；
体积对比：Bun 约 93 MB；Deno 通常约 350 MB（从源码构建的 Linux arm64 因 bug 高达 1.1 GB），且 Deno 内含 Node.js 兼容层；
Node.js 支持最多 CPU/OS，且已用于生产并有可追溯性，支持 s390x——这也是当前 WeKan 生产主栈仍是 Node.js 的原因。

Haxe

Hello world 示例可 transpile 到多种编程语言；
Tinkweb 原型带路由和网页，可转译到 PHP 和 Node.js。

FreePascal

wami 原型：部分静态页面，上传页面上传文件已可用；
之前的 freepascal-router 原型实现了路由与网页；
可运行于大量复古与现代 OS，但不支持 s390x。

FreeDOS 和 Bash

DOS 版：.bat脚本显示菜单，用 SQLite 的 DOS 版查询 WeKan 的 SQLite 数据库；
Bash 版：.sh脚本显示菜单，用 SQLite CLI 做同样的查询。

Minio

用 Bash 脚本和 CLI 二进制，把文本数据与附件从 MongoDB 迁移到 SQLite 和 Minio；
Minio 有 Node.js、Go 等官方驱动。

CloudFlare Workers

正在评估的方向：Workers/Pages、Miniflare、D1 SQLite、Kysely 查询构建器、Hono、WebGPU、CloudFlare TV、KV 存储的 TODO 示例。

Swap 微框架 vs HTMX

对比评估两个轻量前端方案，探讨用极小的 JS 实现交互的可能性。

Ruby on Rails

weror 原型：密码注册登录可用，有工作区与拖拽卡片，但尚无用户管理等完整功能。

路线图的未来走向

Multiverse 文档明确指出：

未来是否发生、用什么技术发生，请见 FUTURE.md（该文件 2023-11 后把导入/导出/同步相关 issue 移交到 Wiki 的 Big Picture Roadmap，平台类 issue 则统一以"最新 WeKan 支持的平台列表"为准）；
维护者 xet7 曾在 EU NGI Dapsi 上以"WeKan Open Source kanban：增加多 Import/Export/Sync 选项与 UI Designer，使其能创建任何应用"为主题发表演讲；
任何人都可以向任一原型仓库提交 PR 来参与。

结语

WeKan Multiverse 路线图的独特价值，在于它把"跨平台"从一句口号变成了一张可执行、可验证的技术地图：用 qemu-user 兜底 AVX 缺失的 CPU，用 FerretDB/SQLite 绕开 MongoDB 的架构限制，用十多个原型逐一回答"换技术栈行不行"。对开发者而言，这份文档既是一次开源项目选型决策的完整现场，也是一份"如何在极端异构环境中保持软件生命力"的实战参考——而其沉淀在 snapcraft.yaml、start-wekan.sh、releases 以及 docs/Design/Multiverse 中的工程细节，远比路线图本身更值得研读。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析