Kylix 项目追踪（三十一）：v4.0.0 正式发布！LLVM M3 让原生后端跨过生产可用线

发布时间： 2026-07-01\ 项目： astra-zhao/kylix $1$ \ 版本： v4.0.0 （Major Release）\ 里程碑： LLVM M3 完整异常处理 + 控制流补全 + 表达式覆盖；stdlib Phase 7 新增 db / cache / http / websocket；VS Code 插件 v1.1 与 25 个代码片段就绪。\ 一句话总结： v3.3.0 让 KylixBoot 变成"工业完整版"，v4.0.0 则让 Kylix 的 LLVM 原生后端第一次真正站上"生产可用基础覆盖"的门槛。

一、第三十一篇的意义：Kylix 的主线切换了

上一篇------第三十篇------我们写的是 v3.3.0：Body Binding、JWT、OpenAPI、包管理器集成、类型检查器 MVP。

那一篇的关键词是：Web 框架成熟。

到了 v4.0.0，关键词变了：原生后端成熟。

这不是一次简单的"又加了几个模块"。如果把 Kylix 从 v3.0-alpha 到 v4.0.0 的轨迹串起来，会看到一条非常清晰的演进曲线：

版本	核心主题	关键变化
v3.0.0-alpha	LLVM 后端破土	LLVM M1、WASI、包注册中心、stdlib Phase 4
v3.1.0	框架与语法并进	KylixBoot 运行时、注解语法、LLVM 数组
v3.2.0	注解栈闭环 + LLVM M2	路由/DI/校验/安全/ORM，接口 fat pointer，泛型单态化，stdlib Phase 6
v3.3.0	KylixBoot 工业完整版	Body 绑定、JWT、OpenAPI、包管理器集成、类型检查器
v4.0.0	LLVM M3 + 生态扩展	异常处理、控制流、表达式覆盖、stdlib Phase 7、VS Code snippets

v3.2.0 和 v3.3.0 解决的是："Kylix 能不能像现代后端框架一样开发 API？"

v4.0.0 回答的是另一个更底层的问题：

Kylix 能不能不再依赖 Go 后端，直接把真实 Pascal 程序编译成原生二进制？

答案从 v4.0.0 开始变得明确：能，而且已经覆盖 14/15 个基础教程，达到 93%。

这就是 v4.0.0 的分量。

二、版本总览：v4.0.0 到底交付了什么？

根据 ROADMAP.md、CHANGELOG.md 与 RELEASE_NOTES_v4.0.0.md，v4.0.0 的交付可以分成三条主线。

主线一：LLVM 后端 Milestone 3

这条主线是本次版本的灵魂。v4.0.0 补齐了此前 LLVM 后端最影响真实程序编译的几块短板：

• 完整异常处理：try/except/finally、raise、类型化 on E: Type do、裸 raise 重抛、嵌套 try
• 控制流补全：break / continue / case / match / foreach
• 表达式覆盖：多参数 WriteLn、零参数 WriteLn、数组字面量、Slice、Tuple、Await 的基础降级
• 字符串插值：${expr} 生成 malloc buffer + strcat/snprintf
• 关键 bug 修复：多变量声明、布尔/整数/浮点自动转换、SSA dominance、构造函数、继承字段布局
• 教程验证：14/15 基础教程通过 LLVM 编译到原生二进制

一句话：LLVM 后端从"能展示"进入"能跑真实基础程序"的阶段。

主线二：stdlib Phase 7

v3.2.0 的 stdlib Phase 6 补的是 net / crypto / encoding，偏底层基础设施。

v4.0.0 的 Phase 7 更偏应用开发：

• db：SQLite/MySQL/PostgreSQL 连接、连接池、参数化查询
• cache：线程安全 LRU + TTL + Sweep 惰性清理
• http：PUT/DELETE/PostJSON、响应对象、客户端方法补全
• websocket：纯 stdlib RFC 6455 客户端 + 服务端基础实现

这四个模块让 Kylix 应用的"后端常用件"更完整：数据库、缓存、HTTP 调用、长连接通讯，基本都是现代服务端开发的日常需求。

主线三：开发者体验

v4.0.0 还补齐了 VS Code 扩展 v1.1：

• KylixBoot 注解高亮
• stdlib 函数高亮
• Kylix: Compile / Kylix: Run 命令与快捷键
• 状态栏 LSP 指示
• 编译器路径解析
• 25 个代码片段：program/unit、function/procedure、class/record、控制流、try/except、WriteLn、Controller、Route、ORM Entity

这件事看似"不如 LLVM M3 硬核"，但对一个语言生态非常重要。

语言不是只靠编译器活着的。真正的使用体验来自：编辑器、补全、片段、错误提示、教程、模板、包管理、文档。v4.0.0 的工具链工作，说明 Kylix 没有把自己做成"实验室里的编译器"，而是在往"可以被普通开发者每天使用的语言"靠近。

三、LLVM M3：v4.0.0 最硬的一块骨头

3.1 异常处理：为什么这是 M3 的标志性成果？

异常处理是语言后端里最容易被低估、也最难写稳的一类功能。

表面看，Pascal 里的异常语法很直观：

复制代码

try
  raise TFooError.Create('bad');
except
  on E: TFooError do
    WriteLn('Custom: ', E.Message);
  on E: Exception do
    WriteLn('Generic: ', E.Message);
finally
  WriteLn('Cleanup');
end;

但到了 LLVM IR 层，这背后牵涉的是：

• 异常对象怎么存？
• 异常类型怎么带？
• handler 链怎么维护？
• finally 怎么保证无论正常返回、异常捕获、异常重抛都执行？
• 类型化捕获 on E: TFooError 怎么做子类型匹配？
• 嵌套 try 怎么处理？

Kylix v4.0.0 选择了一条非常务实的路线：路线 C：全局异常槽 + setjmp/longjmp + 类型 ID。

它没有硬上 Itanium C EH ABI，也就是没有去碰 `invoke` / `landingpad` / `resume` / `_cxa*` 这一套复杂机制。原因也很现实：Kylix 当前是手写 IR 文本生成，C EH ABI 极易错位，而且还会引入 libc++abi 依赖，违背"尽量只依赖 libc"的路线。

setjmp/longjmp 的方案虽然朴素，但可控：

• 全局异常槽保存异常对象、类型信息、消息等
• handler 链用栈式结构维护
• raise 时写入异常槽并 longjmp
• except 分支通过 @__kylix_is_subtype 判断类型是否匹配
• finally 通过三路径代码复制确保确定性执行

这是一种非常"工程现实主义"的选择：不追求理论上的最华丽，而追求当前架构下最稳定、最可验证、最少外部依赖。

对 Kylix 这样的语言项目来说，这种判断很重要。

3.2 控制流补全：从"基础语法"到"正常写程序"

v4.0.0 之前，LLVM 后端虽然已经能处理不少基础语句，但真实程序里一旦出现复杂控制流，就很容易踩坑。

M3 补齐了这些缺口：

• break / continue：循环标签保存/恢复，嵌套循环可正确跳转
• case：降低为 LLVM switch
• match：降低为 icmp eq 链和 OR 多模式
• foreach：字符串/数组遍历基础支持

这些功能不一定"酷"，但它们决定了语言能不能写普通业务逻辑。

一门语言的后端成熟度，往往不是看它能不能跑 Hello World，而是看它能不能处理那些每天都会出现的代码：循环提前退出、多个条件分支、模式判断、遍历集合、异常清理。

v4.0.0 正是在这些"不炫但必要"的地方补课。

3.3 表达式覆盖：把坑一个个填平

表达式层面，v4.0.0 同样做了大量补全：

• WriteLn(a, b, c) 多参数输出
• WriteLn() 空行输出
• ArrayLiteral 堆分配
• SliceExpression 基础覆盖
• TupleLiteral 暂时返回首元素
• AwaitExpression 同步降级
• 字符串插值 ${expr}

这里特别值得注意的是：Kylix 并没有假装所有能力都已经完整。例如 Tuple LHS 赋值目前只是 stub，await 也是同步降级。这种处理方式有两个好处：

1. IR 保持合法，不会因为未覆盖表达式直接炸掉基础编译链路；
1. 限制被明确文档化，后续 v4.1.0 有清晰的修复目标。

这比"半支持但不说明"要健康得多。

四、从 v3.3.0 到 v4.0.0：变化不是加法，而是重心迁移

v3.3.0 和 v4.0.0 相隔只有两天，但这两个版本的重心完全不同。

4.1 v3.3.0：KylixBoot 完整了

v3.3.0 的核心是让 KylixBoot 从"注解能装配"变成"框架可交付"：

• [Body(TEntity)] 请求体绑定
• JwtSign / JwtVerify / BootRegisterJwtAuth
• kylix doc --openapi 生成 OpenAPI 3.1
• packages/* 自动发现和编译
• 类型检查器 MVP：未声明变量/函数、调用参数数量、赋值兼容、泛型约束、接口实现、类型别名循环

它补的是 Web 框架最后的工业缺口：请求、认证、文档、包、类型安全。

4.2 v4.0.0：LLVM 后端可用了

v4.0.0 则回到底层，把 LLVM 后端推过一个关键门槛：

• v3.0-alpha：LLVM 后端出现
• v3.1.0：数组与优化旗标雏形
• v3.2.0：接口 fat pointer + 泛型单态化
• v4.0.0：异常、控制流、表达式覆盖，14/15 基础教程通过

也就是说，v3.3.0 是"上层框架补齐"，v4.0.0 是"底层后端补齐"。

这两者合在一起，Kylix 的产品轮廓开始稳定下来：

上层有 KylixBoot，能写现代 Web API；下层有 Go 后端兜底，也有 LLVM 后端走原生二进制。

这正是 Kylix 与很多玩具语言项目拉开距离的地方。它不是只做语法，也不是只做运行时，而是在同时补齐"语言 --- 编译器 --- 标准库 --- 框架 --- IDE --- 教程 --- 发布流程"。

五、stdlib Phase 7：从"基础设施"走向"应用开发件"

如果说 LLVM M3 是 v4.0.0 的"硬核底座"，那么 stdlib Phase 7 就是 v4.0.0 的"应用肌肉"。

5.1 `db`：数据库访问终于变成一等能力

v4.0.0 新增 db 模块，支持：

• SQLite / MySQL / PostgreSQL
• DbOpen / DbOpenSQLite
• DbExec
• DbQueryRows
• DbQueryScalar
• DbClose
• 参数化查询 ? 占位符

教程里的 example52_database.klx 用 SQLite 内存库展示了完整流程：打开数据库、建表、插入、查询、关闭。

这意味着 Kylix 的服务端故事更完整了。此前有 ORM 注解和 KylixBoot，但数据库底层便捷封装仍需要补强；Phase 7 把这块补上。

5.2 `cache`：LRU + TTL，不只是 map 包一层

cache 模块实现了线程安全 LRU 缓存：

• container/list + map，O(1) 操作
• TTL 过期
• Sweep 惰性回收
• Put / GetString / Has / Delete / Size / Clear

这不是一个"临时 map helper"，而是有明确语义的缓存模块。

对 Web 服务来说，本地缓存是非常常见的组件；对语言标准库来说，把它纳入 stdlib 能显著降低应用开发门槛。

5.3 `http`：从能请求，到更像真实客户端

v4.0.0 对 HTTP 模块做了增强：

• HttpPut
• HttpDelete
• HttpPostJSON
• THttpResponse：Status + Body
• HttpDoGet / HttpDoPost
• THttpClient.Put / Delete

此前 HTTP 更像"能发 GET/POST 的工具函数"，现在则更像一个完整客户端抽象。

5.4 `websocket`：长连接能力进入 stdlib

WebSocket 模块支持：

• WsDial
• WsAccept
• WsSend
• WsRecv
• WsClose
• RFC 6455 握手
• 文本帧
• ping 自动 pong
• close 帧处理

这对实时应用、推送、协作编辑、游戏、监控面板都很关键。

当然，从当前教程看，WebSocket 示例还是偏"接口演示"而非完整 echo server 压测。但作为 Phase 7 的第一版，它已经把 stdlib 的边界从传统请求/响应推进到了长连接。

六、完整教程：从 45/45 到 49/49，再到 55+ 的路线

examples/complete-tutorial/README.md 是观察项目成熟度的好窗口。

v3.3.0 的教程重点是：

• example49：Body Binding
• example50：JWT Authentication
• example51：OpenAPI / Swagger

v4.0.0 新增了四个 Phase 7 示例：

• example52：Database
• example53：Cache
• example54：HTTP Client
• example55：WebSocket

Release Notes 写的是：Go 后端教程 49/49 通过，LLVM 基础教程 14/15 通过。

这里有一个细节值得说明：教程 README 里还有一些旧标题和旧描述，例如开头仍写着 "Kylix v3.1.1 Complete Tutorial" 和 "v3.3.0"，但后文已经列出了 v4.0 Phase 7 的 example52--55。也就是说，内容已经向 v4.0.0 更新，文档标题和若干统计口径还需要进一步同步。

这不影响 v4.0.0 的技术主线，但从发布工程角度看，是后续 v4.0.1 或文档修订可以顺手清理的地方。

为什么我要特别提这个？因为一个语言项目到了 v4.0.0，问题已经不只是"功能有没有"，而是"信息是否一致、用户是否容易理解"。文档一致性本身就是产品成熟度的一部分。

七、发布工程观察：v4.0.0 已发布，但 checklist 暴露了几个后续清理点

docs/v4.0.0-release-checklist.md 很有意思。

它的目标日期写的是 2026-07-07，Release Notes 仍被标记为未创建，但仓库中实际已经存在 RELEASE_NOTES_v4.0.0.md，并且 ROADMAP 与 CHANGELOG 都显示 v4.0.0 已于 2026-07-01 发布。

这说明什么？

不是坏事。相反，它说明项目在高速推进中，发布动作已经跑到 checklist 前面去了。但它也提醒：

• checklist 状态需要回填
• 教程 README 标题与统计需要统一到 v4.0.0
• ROADMAP 里的部分历史 issue 状态仍有旧标记，例如 LLVM L02/L03 在上方版本记录中已完成，但问题跟踪表里仍显示 v3.2 待办
• 依赖校验需要补齐，当前仓库浅克隆后运行部分测试会提示缺少 go.sum 条目（如 MySQL/PostgreSQL/SQLite/bcrypt/liner）

这些不是"架构问题"，而是"发布卫生问题"。

但正因为 v4.0.0 已经是 Major Release，这类细节会越来越重要。用户看到的是整体体验：能不能 clone，能不能 test，文档是不是一致，Release checklist 是否闭环。

Kylix 现在已经走到需要认真对待这些细节的阶段了。

八、关键数字：v4.0.0 的成熟度快照

从本次文档给出的数据看，v4.0.0 的项目规模已经相当可观：

指标	v4.0.0 状态
Go 测试包	16 个
Go 级测试	350+
Kylix 级 stdlib 测试	140+
纯 Kylix stdlib 函数	110+
CLI 命令	19 个
教程示例	55+ 个口径；当前 complete-tutorial 中 example 文件到 example55
原生构建目标	linux / darwin / windows × amd64 / arm64
WASM 目标	Go 标准 + TinyGo
WASI 目标	Go wasip1 + TinyGo
LLVM 后端	Milestone 3
LLVM 测试	Release Notes 口径 73 个
LLVM 教程编译通过率	14/15（93%）
KylixBoot 测试	23 个
VS Code 扩展	v1.1，含 25 个 snippets

这里最关键的不是"数字多"，而是覆盖面已经很宽：

• 编译器
• 标准库
• Web 框架
• 包管理
• 文档生成
• IDE 插件
• WASM/WASI
• LLVM 原生后端
• 教程与示例

这已经不是单点项目，而是一个语言生态雏形。

九、v4.0.0 的已知限制：成熟项目敢于说"不完整"

v4.0.0 没有假装自己已经无所不能。Release Notes 和 LLVM Guide 都明确列出了限制。

9.1 Lambda / 闭包仍未支持

example15_lambda.klx 是 14/15 里唯一失败的那个。

原因是 LLVM 后端目前对 lambda 仍是 null pointer stub。真正支持闭包，需要：

• 捕获变量分析
• environment struct
• lambda body 降级为命名函数
• {func_ptr, env_ptr} 闭包结构
• 调用约定
• 嵌套闭包与可变捕获处理

这不是小修小补，而是完整编译器功能。

9.2 多返回值还只是"合法 IR"，不是完整语义

(q, r) := DivMod(...) 当前会降级为注释，保证 IR 合法，但变量不会被真正赋值。

v4.1.0 的计划是用结构体返回类型 + insertvalue / extractvalue 实现真正的 tuple destructuring。

9.3 `inherited` 关键字未实现

父类方法调用需要类层次查询、绕过 vtable 的直接调用、正确传 this 指针。这也是 v4.1.0 的目标。

9.4 优化通道还不完整

LLVM 当前生成代码比 Go 后端慢 2--5 倍。v4.1.0 计划加入 --llvm-opt，通过 LLVM opt 做内联、循环优化、DCE，并以 O2 下接近 Go 后端 1.5x 为目标。

这些限制让 v4.0.0 的定位更加准确：

它不是"LLVM 后端完全体"，而是"LLVM 后端生产可用基础覆盖"。

这个表述很重要。它既肯定了阶段性突破，也没有过度承诺。

十、v4.1.0 / v4.2.0 / v5.0：路线图开始变得更像长期工程

ROADMAP 对 v4.0.0 之后的规划非常清楚。

v4.1.0：LLVM M4 高级特性

目标：让 LLVM 后端在常见用例上接近 Go 后端。

优先级包括：

1. Lambda / 闭包支持
1. 完整多返回值
1. inherited 关键字
1. 优化通道

成功指标：

• LLVM 教程通过率从 14/15 扩展到 25+/35
• LLVM 测试从 73 增加到 120+
• example15_lambda 通过
• O2 优化下性能明显提升

如果说 v4.0.0 是"基础覆盖"，v4.1.0 就是"高级语言特性补齐"。

v4.2.0：LLVM 工具链深化

v4.2.0 的关键词是工具链：

• 增量编译 LLVM IR
• DWARF 调试符号
• 交叉编译
• LLVM stdlib Phase 1
• logging / profiling / reflection / httpserver / Redis cache
• JetBrains 插件
• DAP 调试适配器
• 包注册中心正式上线

这一步如果完成，Kylix 的 LLVM 后端就不只是"能生成二进制"，而是开始具备真实工程开发体验：快、可调试、可交叉构建、可接入 IDE。

v5.0.0：完全脱离 Go

长期目标仍然是最激动人心的：

复制代码

.klx → LLVM IR → 原生二进制（无 Go 依赖）

v5.0.0 的关键词是 KylixRT、自研运行时、stdlib 纯 Kylix 重写、自举编译器。

这是一条很长的路，涉及：

• GC 或内存管理
• 字符串 / 动态数组 / map 运行时
• 协程或线程池
• stdlib 去 Go wrapper
• Kylix 编译器用 Kylix 重写

但 v4.0.0 的意义就在这里：它让 v5.0.0 不再只是愿景，而是有了阶段性前提。

LLVM M3 证明了：Kylix 的原生后端路线不是空想。

十一、我的判断：v4.0.0 是 Kylix 的"第二个成人礼"

如果要给 Kylix 的发展划几个成人礼，我会这样分：

• 第一个成人礼：v1.2.x 自举验证，证明"Kylix 能编译 Kylix 相关核心代码"
• 第二个成人礼：v4.0.0 LLVM M3，证明"Kylix 能不靠 Go 后端编译真实基础程序到原生二进制"
• 第三个成人礼：未来 v5.0.0，证明"Kylix 能完全脱离 Go，拥有自己的运行时和自举编译器"

v4.0.0 站在中间。

它不像 v1.0 那样是"从 0 到 1"；也不像 v5.0 那样是"完全独立"。它更像一个桥：一端连接过去已经成熟的 Go 后端和 KylixBoot，另一端通向未来的 KylixRT、自研运行时和完全原生生态。

这就是"承上启下"的真正含义。

十二、可圈可点之处：这次版本最值得夸的五件事

第一，LLVM 异常处理路线选择非常务实

没有为了"高级"而硬碰 C++ EH ABI，而是选择 setjmp/longjmp 方案。对当前手写 IR 的架构来说，这是正确的工程选择。

第二，v4.0.0 没有回避限制

Lambda、tuple destructuring、inherited、优化问题都写进文档，而且给出 workaround 和 v4.1.0 ETA。成熟项目不是没有缺点，而是缺点清楚、边界清楚、计划清楚。

第三，stdlib Phase 7 抓住了应用开发核心需求

数据库、缓存、HTTP、WebSocket，不是边角料，而是服务端开发的高频模块。

第四，教程持续扩展

example52--55 把 v4.0.0 的新增模块直接落到可运行示例里。语言项目最怕"功能只存在于 CHANGELOG"，Kylix 至少在努力把功能变成教程。

第五，路线图从版本规划变成工程战略

v4.1 做语言高级特性，v4.2 做工具链，v5.0 做运行时和完全脱 Go。这个分层是清晰的。

十三、也该冷静指出的三个风险

风险一：文档一致性需要跟上发布速度

教程 README、release checklist、ROADMAP issue 表里仍有一些旧口径。这不影响核心功能，但会影响外部用户信任。

建议 v4.0.1 或文档修订中优先清理：

• README 标题统一到 v4.0.0
• 教程数量口径统一
• checklist 状态回填
• ROADMAP 历史 issue 状态同步

风险二：依赖锁文件与可复现测试要补齐

当前浅克隆后尝试运行部分 Go 测试，会遇到 go.sum 缺失条目提示。对开源项目来说，git clone && go test ./... 是非常关键的第一印象。

建议尽快补齐 go.sum 并在 CI 中验证全量测试。

风险三：LLVM 后端进入"难啃区"

v4.1.0 的闭包、多返回值、inherited、优化，都不是简单 feature。尤其闭包会触及捕获分析、逃逸、调用约定、内存生命周期。这里需要比 M3 更强的测试设计。

换句话说，v4.0.0 解决了"能不能跑起来"，v4.1.0 要解决的是"能不能优雅地跑复杂语言特性"。

十四、结语：从"写 Pascal 生成 Go"到"写 Pascal 生成原生二进制"

Kylix 最早给人的印象，是一个现代 Pascal-to-Go 转译器。

后来它有了 LSP、REPL、包管理器、自举、标准库、KylixBoot、注解、OpenAPI、JWT。

现在，v4.0.0 又把故事往前推了一步：

Kylix 不再只是"Pascal 写法 + Go 后端"的组合，它开始拥有自己的原生编译路线。

这条路线还没有走完。Lambda 还没补，tuple destructuring 还没完整，inherited 还没实现，优化还需要打磨，stdlib 还没有完全 LLVM 化，KylixRT 还在远方。

但 v4.0.0 已经足够重要。

因为它把一个长期愿景从"路线图上的字"变成了"14/15 基础教程能编译成原生二进制"的现实。

这就是编译器项目最迷人的地方：每一个 milestone 都不是终点，而是下一层可能性的地基。

v3.3.0 让 KylixBoot 成为工业完整版。

v4.0.0 让 LLVM 后端跨过生产可用基础线。

v4.1.0 将决定它能否覆盖更复杂的真实语言特性。

v5.0.0 则会回答最终的问题：Kylix 能否成为一个完全独立、自举、自带运行时的现代 Pascal 语言？

现在，答案正在变得越来越接近"能"。

本文是 Kylix 项目追踪系列的第三十一篇，基于 2026 年 7 月 1 日仓库状态、ROADMAP.md、CHANGELOG.md、examples/complete-tutorial/README.md、docs/v4.0.0-release-checklist.md 与 RELEASE_NOTES_v4.0.0.md 编写。

引用链接

[1] astra-zhao/kylix: https://github.com/astra-zhao/kylix