Kylix v3.1.0 深度解析：从架构突破到应用框架

Kylix 连续观察 · 第二十六篇

项目地址：https://github.com/astra-zhao/kylix\\

版本聚焦：v3.1.0

发布日期：2026-06-23

关键词：KylixBoot、Spring Boot 风格框架、注解语法、DI、Router、Compiler Fixes、LLVM Arrays、LLVM Optimization、stdlib symbol injection

开篇：第二十六篇，Kylix 开始从"能生成什么"转向"能构建什么"

上一篇第二十五篇，我们分析的是 Kylix v3.0.0-alpha。

那是一个非常醒目的版本：LLVM 原生后端、WASI、包注册中心、标准库 Phase 4，一次性把 Kylix 从"编译到 Go 的现代 Pascal"推向"多后端语言基础设施"。

当时最核心的判断是：

Kylix 正式从"编译到 Go 的 Pascal"进化为"多后端架构的现代语言"。

而 v3.1.0 的意义，恰好在于回答 v3.0.0-alpha 之后的下一个问题：

架构突破之后，Kylix 要拿这些能力构建什么？

v3.0.0-alpha 证明了 Kylix 可以拥有 LLVM 后端、WASI 目标、包注册中心、纯 Kylix 标准库；v3.1.0 则开始把这些底层能力向应用开发体验收束。

这一次的主角不是单纯的编译器，不是单纯的后端，也不是单纯的工具链，而是一个更接近"开发者日常工作流"的关键词：

KylixBoot。

v3.1.0 新增 pkg/boot/ 框架核心运行时，提供路由、HTTP Server、DI 容器、配置、中间件、全局快捷 API，并通过 stdlib/boot_bridge.go 与 stdlib/klx/boot.klx 接入 Kylix 标准库与 LSP 声明。

与此同时，Kylix 语言层新增 [Name] / [Name(args)] 注解语法。它现在还只是 AST 与 Parser 层的基础设施，但方向非常明确：为 v3.2 的自动路由注册、ORM 映射、校验注解、安全注解、DI 自动装配铺路。

此外，v3.1.0 还集中修复了五个编译器关键问题：

• var p: TClass 不再错误生成 interface{}
• 单引号字符串中的 ${...} 可以正确识别为字符串插值
• lambda / 匿名函数返回类型不再丢失
• match 语句不再生成无效 Go 代码
• uses sysutil/jsonutil/datetime/regex/httpclient 在 program 文件中可以正确注入符号

最后，LLVM 后端也从 v3.0.0-alpha 的 Milestone 1 继续向前推进：v3.1.0 完成 Milestone 2 Phase 1 ，支持静态数组、动态数组、Pascal 1-based 索引转换、数组大小常量求值，以及 --llvm-opt=0/1/2/3 优化等级。

一句话概括 v3.1.0：

v3.1.0 是 Kylix 从"架构突破"走向"应用框架"的版本：上层有 KylixBoot 与注解语法，下层有 LLVM 数组与优化，中间用五个编译器修复打通真实开发路径。

一、版本总览：从 v3.0.0-alpha 到 v3.1.0，8 个提交补齐 4 条主线

从仓库变化看，v3.1.0 相对 v3.0.0-alpha 主线新增了 8 个关键提交：

• 6f18bc9 --- KLX-C05：修复 uses 在 program 文件中的符号注入
• ff867f5 --- KLX-C01：修复 var p: TClass 生成 interface{} 的问题
• d8dbc6e --- KLX-C02/C03/C04：修复字符串插值、lambda 返回类型、match codegen
• aee3de2 --- KylixBoot 注解语法支持（Lexer / Parser / AST）
• 0456876 --- KylixBoot 框架核心运行时 Phase 1
• d37db1f --- LLVM Milestone 2：数组 + 优化 Phase 1
• 52fb999 --- v3.1.0 release 文档更新
• 以及 v3.0.0-alpha 后续教程文档补全提交

从 fbf3141..origin/main 的 diff 看，本轮变化覆盖 55 个文件：

• 3855 行新增
• 865 行删除
• 净增约 2990 行

重点新增模块包括：

方向	新增/修改内容	代表文件
KylixBoot 框架	Router、Server、DI、Config、Middleware、App、Types	`pkg/boot/*.go`
标准库桥接	将 boot runtime 暴露给 Kylix 程序	`stdlib/boot_bridge.go` 、`stdlib/klx/boot.klx`
注解语法	`ast.Attribute` 、Parser 支持 `[Name(args)]`	`ast/ast.go` 、`parser/parser_attribute.go`
编译器修复	class 类型、字符串插值、lambda、match、uses stdlib	`generator/` 、`lexer/lexer.go`、`parser/`
LLVM 数组	静态/动态数组 codegen、优化等级	`pkg/llvmgen/array.go` 、`cmd/kylix/cmd_build.go`
教程示例	OOP、stdlib、attributes 示例补齐	`examples/complete-tutorial/*`
文档	README / CHANGELOG / ROADMAP / TASKS 全部更新到 v3.1.0	根目录文档

如果 v3.0.0-alpha 是一次"从 2 到 3"的架构升级，那么 v3.1.0 就是一次非常典型的"架构落地版本"：它没有继续盲目扩大新概念，而是围绕 v3.0 已经打开的方向，补框架、补语法、补缺陷、补后端能力。

这类版本通常比"震撼发布"更重要。

因为它决定一个项目是停留在 demo，还是走向可持续开发。

二、KylixBoot：Kylix 的应用框架雏形终于出现

v3.1.0 最大的新内容，是 pkg/boot/。

CHANGELOG 中对它的定位很明确：

Spring Boot-style Runtime Core

也就是说，KylixBoot 不是简单的 HTTP helper，而是朝着"声明式 Web 应用框架"演进的核心运行时。

2.1 KylixBoot 提供了什么

本次新增 pkg/boot/，约 700 行，实现 7 个核心文件：

文件	职责
`types.go`	Request、Response、Handler、Middleware 基础类型
`router.go`	路由匹配与路径参数，例如 `/users/:id`
`server.go`	HTTP Server 与 graceful shutdown
`di.go`	DI 容器，支持 Singleton / Transient / Instance 与反射注入
`app.go`	App 对象与全局快捷方式：`boot.GET`、`boot.POST`、`boot.Use`、`boot.Listen`
`config.go`	配置读取，支持环境变量 fallback
`middleware.go`	Logger、Recover、CORS、Auth、RateLimit、RequestID 等内置中间件

这套组合已经具备一个现代 Web 框架的最小闭环：

复制代码

program HelloBoot;
uses boot;

begin
  boot.GET('/', procedure(req: TRequest; res: TResponse)
  begin
    res.Send('Hello, KylixBoot!');
  end);

  boot.GET('/users/:id', procedure(req: TRequest; res: TResponse)
  begin
    res.JSON(record id := req.Param('id'); end);
  end);

  boot.Use(boot.Logger());
  boot.Use(boot.Recover());
  boot.Use(boot.CORS());

  boot.Listen(':8080');
end.

这个例子背后其实包含几件关键事情：

1. 路由系统 ：不只是固定 path，而是支持 /users/:id 这种路径参数
1. 请求响应抽象 ：Kylix 侧可以操作 TRequest / TResponse
1. 中间件机制：Logger、Recover、CORS 等可组合
1. 服务生命周期：Server 层支持优雅停机
1. 标准库暴露 ：通过 stdlib/boot_bridge.go 与 stdlib/klx/boot.klx 让 Kylix 程序可见

这说明 KylixBoot 的目标不是写一个"能跑 HTTP 的 demo"，而是在搭一个真正的应用层框架。

2.2 DI 容器：从工具函数走向应用组织方式

KylixBoot 的另一个关键点，是 DI 容器。

本次 di.go 支持：

• Singleton
• Transient
• Instance
• reflection-based Inject

示意代码如下：

复制代码

container := boot.NewContainer();
container.RegisterSingleton('UserService', TUserService);
container.RegisterTransient('Request', TRequestScope);
container.Inject(controller);

为什么这很重要？

因为一门语言要进入后端应用开发，最终一定会遇到对象生命周期、服务组织、配置注入、模块拆分的问题。

早期语言项目通常喜欢展示语法：函数、类、泛型、循环、异常、Web server。但当项目真正变大时，开发者需要的不是"如何写一个 handler"，而是：

• Controller 如何依赖 Service？
• Service 如何依赖 Repository？
• Repository 如何拿到数据库连接？
• 配置如何注入？
• 测试时如何替换实现？
• 请求级对象和全局单例如何区分生命周期？

DI 容器回答的正是这些问题。

这也是为什么 KylixBoot 一出现，就把 Kylix 从"语言 + 标准库"推向了"应用架构"的方向。

2.3 23 个测试：框架不是 PPT，而是可验证模块

pkg/boot/boot_test.go 新增 23 个测试，全部通过。

这点很关键。

Kylix 从 v2.x 开始就一直强调测试体系：stdlib 有 Kylix 级测试，LSP 有单元测试，registry 有集成测试，LLVM 有 codegen 测试。v3.1.0 对 KylixBoot 也延续了这种工程纪律。

一个框架的早期版本最怕什么？

不是功能少，而是边界不清、行为不稳定、后续难以演进。

23 个测试意味着 KylixBoot 从第一天起就不是"先写出来再说"，而是被纳入了 Kylix 已经形成的工程质量体系。

三、注解语法：v3.1 先铺轨，v3.2 才是列车进站

Kylix v3.1.0 的第二个重要变化，是新增 [Name] / [Name(args)] 注解语法。

这不是语法糖那么简单。

它是 KylixBoot 真正走向声明式编程的入口。

3.1 AST 层新增 `ast.Attribute`

本次新增 ast.Attribute 类型，包含：

• Name
• Args

并给以下 AST 节点新增 Attributes []*Attribute 字段：

• ClassDecl
• TypeDecl
• FunctionDecl
• VarDecl

同时新增 parser/parser_attribute.go，支持在顶层与 class body 内解析注解。

示例：

复制代码

[Controller('/api/users')]
type
  TUserController = class
    [Inject]
    UserRepo: TUserRepository;

    [Get('/')]
    function ListUsers(req: TRequest): TResponse;
    begin
      result := req.JSON(UserRepo.FindAll());
    end;

    [Post('/'), Authenticated]
    function CreateUser(req: TRequest): TResponse;
    begin
      var user := req.Body();
      UserRepo.Save(user);
      result := req.Created(user);
    end;
  end;

这段代码现在的意义，不是"已经完整自动注册路由"，而是：

Kylix 的语法树已经能够表达 Controller、Route、Inject、Entity、Column、Validation 等元信息。

语言设计里，这一步非常关键。

因为没有 AST 级元信息，后续所有自动化都只能靠命名约定、注释解析、外部配置或运行时反射。

而 Kylix 选择的是编译期注解路线。

这与 ROADMAP 中的设计决策一致：

第一阶段用代码生成实现注解语义，不依赖运行时反射；第二阶段等 LLVM 后端成熟后迁移到编译时属性处理。

3.2 为什么注解是 KylixBoot 的"第二发动机"

KylixBoot 的第一阶段 API 是命令式的：

复制代码

boot.GET('/users/:id', handler);
boot.Use(boot.Logger());
boot.Listen(':8080');

这很好，简单、直接、可测试。

但大型应用通常更适合声明式组织：

复制代码

[Controller('/users')]
type
  TUserController = class
    [Get('/:id')]
    function GetUser(req: TRequest): TResponse;
  end;

两者差别在哪里？

命令式 API 关注"怎么注册"；声明式注解关注"它是什么"。

• [Controller] 表示这是控制器
• [Get] 表示这是 GET 路由
• [Inject] 表示这个字段由容器注入
• [Entity] 表示这是数据库实体
• [Column] 表示字段映射关系
• [Required] / [Email] 表示校验规则
• [Authenticated] 表示安全策略

一旦这些元信息进入 AST，编译器就可以在编译期生成注册代码、DI wiring、ORM mapping、校验逻辑，甚至给出诊断。

这就是 v3.2 的任务清单：

• 编译时扫描 [Controller('/path')] 类，自动注册路由
• [Get] / [Post] / [Put] / [Delete] 方法注解注册到路由表
• [Inject] 字段生成 container.Resolve(...)
• [Component] / [Service] 自动注册到容器
• [Entity] / [Column] / [PrimaryKey] 映射 ORM
• [Required] / [Email] 等校验注解自动生成 400 响应

所以 v3.1 的注解语法不是终点，而是轨道。

v3.2 才是列车进站。

四、五个编译器修复：v3.1.0 真正可贵的是"打通真实开发阻塞点"

如果只看标题，v3.1.0 最亮眼的是 KylixBoot 和注解语法。

但如果从"项目能不能真的写起来"的角度看，KLX-C01 到 KLX-C05 这五个修复同样重要，甚至可以说是 v3.1.0 的地基工程。

4.1 KLX-C01：`var p: TClass` 不再生成 `interface{}`

之前的问题是：

复制代码

var p: TPerson;
p.Name := 'Astra';

当类被包在 TypeDecl 或涉及继承时，生成器可能把 TPerson 生成成 interface{}，导致字段访问失败。

v3.1.0 修复后：

• generator/generator_types.go 对 class types 始终 emit *TypeName
• generator 扫描 TypeDecl 包裹的 ClassDecl 方法体以补齐 imports
• uses sysutil 活跃时跳过错误的 os.ReadFile inline
• error-returning stdlib 函数使用具体返回类型包装

这个问题看似是 codegen 细节，实际影响很大。

因为 KylixBoot、ORM、Controller、Entity 全部离不开类类型。如果 var p: TClass 这种基础场景都不稳定，声明式 OOP 与 DI 就无从谈起。

所以 KLX-C01 是 v3.1 面向应用框架必须先修的 bug。

4.2 KLX-C02：字符串插值恢复为现代语言基本体验

Kylix 支持：

复制代码

WriteLn('Hello, ${name}!');

但之前单引号字符串中的 ${...} 可能被 lexer 当成普通 STRING，而不是 STRING_INTERPOLATION。

v3.1.0 修复 lexer/lexer.go，让包含 ${...} 的单引号字符串正确进入插值路径。

这类 bug 不大，但非常影响语言观感。

因为字符串插值属于现代语言的"基础舒适性"：日志、错误消息、HTTP 响应、SQL 调试、模板输出都会用到。

KylixBoot 进入 Web 场景后，这个修复更有意义。

4.3 KLX-C03：lambda / 匿名函数返回类型不再丢失

之前匿名函数：

复制代码

var add := function(a: Integer; b: Integer): Integer
begin
  result := a + b;
end;

可能在 AST 或 generator 阶段丢失返回类型。

v3.1.0 中：

• ast.LambdaExpression 新增 ReturnType
• Parser 保存返回类型
• Generator emit 返回类型、var result T、return result

这对框架代码同样重要。

因为 Web handler、中间件、回调、函数式工具、测试 fixture 都可能依赖匿名函数。返回类型不稳定，意味着很多现代写法只能停留在文档里。

4.4 KLX-C04：`match` 语句 codegen 不再生成无效 Go

之前 match 可能生成类似：

复制代码

switch _v := ... {
case _v == 1:
}

这是无效 Go。

v3.1.0 改为 tagless switch：

复制代码

switch {
case _v == p:
}

这才符合 Go 的布尔 case 写法。

match 是 Kylix 现代语法的一部分。它不只是炫技，而是未来写业务规则、状态机、错误分类、路由分发时非常自然的表达方式。

这个修复让 Kylix 的"现代 Pascal"叙事更可信。

4.5 KLX-C05：`uses` 符号注入，解锁 40+ stdlib 函数

这是五个修复里最关键的一个。

之前在 program 文件里：

复制代码

uses sysutil, jsonutil, datetime, regex, httpclient;

可能仍然生成未定义函数调用。

v3.1.0 引入：

• usedModules map[string]bool
• generator/generator_stdlib.go，约 270 行
• stdlib module name → function set 映射
• resolveStdlibFunc() 检查函数归属
• generateStdlibCall() 生成 stdlib.FuncName(...)
• 对返回 (T, error) 的函数包装为具体返回类型

结果是：

uses sysutil/jsonutil/datetime/regex/httpclient 在 program 文件中可以真正使用，40+ 标准库函数被解锁。

这非常重要。

因为 v3.0.0-alpha 花了大量精力把 jsonutil、regex、datetime、httpclient 做出来；如果 program 文件里 uses 后仍然不可见，那标准库就只是"存在"，还不是"可用"。

KLX-C05 把标准库从"文档能力"变成"开发能力"。

这也是 v3.1.0 作为承上启下版本最漂亮的一笔：它没有继续堆新库，而是把已有库接通。

五、LLVM Milestone 2 Phase 1：数组与优化让原生后端走出玩具阶段

v3.0.0-alpha 的 LLVM 后端已经跑通了端到端：AST → LLVM IR → llc → clang → native binary。

但它的限制也很明确：Milestone 1 不支持数组、接口、泛型、异常，优化为 -O0。

v3.1.0 开始进入 Milestone 2。

第一阶段交付的是：数组 + 优化等级。

5.1 静态数组：`array[1..N] of T` → `[N x T]`

新增 pkg/llvmgen/array.go，约 200 行，实现静态数组 codegen：

复制代码

var nums: array[1..10] of Integer;

映射到 LLVM：

复制代码

alloca [10 x i64]

这看似直接，但 Pascal 数组有一个重要特点：索引常常是 1-based。

Kylix 的 LLVM 后端需要把 Pascal 侧的 array[1..N] 自动转换为 LLVM 的 0-based GEP 索引。

也就是说：

复制代码

nums[1]

在底层应访问第 0 个元素。

这不是语法问题，是语义保存问题。

v3.1.0 完成了这个转换。

5.2 动态数组：`array of T` → slice struct

动态数组被表示为：

复制代码

{ ptr, i64, i64 }

也就是典型的 slice 结构：

• data pointer
• length
• capacity

这个设计很关键。

因为它已经为未来自研运行时 KylixRT 铺好了内存模型入口。动态数组不是简单地"先用 Go slice 混过去"，而是在 LLVM 后端建立了自己的数据结构表达。

这与 ROADMAP 中 v4.0 的目标一致：未来 Kylix 要有自己的动态数组运行时、字符串运行时、GC / RC 策略。

v3.1 的动态数组结构，就是这条路的早期地基。

5.3 编译期常量求值：数组大小不能只靠字面量

CHANGELOG 特别提到：

Compile-time constant evaluation for array sizes，handles array[1..N] desugared to ((N-1)+1)

这说明实现不是只支持最简单的 array[1..10]，而是开始处理数组大小表达式。

这对 Pascal 风格数组很重要，因为区间类型、常量表达式、枚举范围未来都会影响数组大小计算。

先把常量求值接上，后续扩展会顺很多。

5.4 `--llvm-opt=0/1/2/3`：原生后端开始进入优化阶段

v3.1.0 新增：

• CompileOpts.OptLevel
• CLI flag：--llvm-opt=0/1/2/3
• 调用 llc -O=N

命令形态：

复制代码

kylix build --backend=llvm --llvm-opt=2 main.klx

这意味着 LLVM 后端不再只是"能生成 native binary"，而是开始提供优化配置。

虽然这还不是完整的 Kylix 优化体系，但很重要：它把优化入口接进了正式 CLI。

从此，Kylix 的构建命令开始具备真正 native compiler 的味道。

5.5 测试增长：LLVM 测试从 24 到 30

v3.0.0-alpha 中 LLVM 后端有 24 个测试。

v3.1.0 新增 pkg/llvmgen/array_test.go，6 个数组测试，LLVM 测试总数达到 30。

这说明 LLVM 后端的推进方式仍然稳健：每补一个语言特性，就补对应 codegen 测试。

对于编译器项目来说，这是生命线。

六、和之前版本相比，v3.1.0 的主题变了：从工具链、性能、架构，到应用开发

把 v2.4.0 到 v3.1.0 放在一起看，Kylix 的演进路径非常清楚：

版本	主题	关键词	意义
v2.4.0	完善与生态	i18n、真实类型推导、SetLength、嵌套依赖、lockfile	让已有能力更可信
v2.5.0	工具链深化	LSP rename、codeAction、doc 示例、bench --mem、iter	让开发手感更顺
v2.6.0	性能与优化	并行编译、DCE、LSP 性能基准	让工程规模更可控
v3.0.0-alpha	架构突破	LLVM、WASI、Registry、stdlib Phase 4	从 Go 转译器迈向多后端语言
v3.1.0	应用框架落地	KylixBoot、注解语法、编译器修复、LLVM 数组	从底层能力走向真实应用开发

这条路径很漂亮。

v2.4 到 v2.6，是"把工具链做实"。

v3.0，是"把架构边界打开"。

v3.1，则是"把架构能力收束到应用模型"。

也就是说，Kylix 没有陷入常见的语言项目陷阱：只顾语法炫技，或者只顾底层后端，或者只顾 Web 框架而忽略编译器质量。

它在三个层面同时推进：

1. 语言层：注解、lambda 返回类型、match、字符串插值
1. 编译层：class 类型、uses 注入、LLVM 数组、优化等级
1. 应用层：KylixBoot、DI、Router、Middleware、Config

这就是 v3.1.0 最可圈可点的地方。

它不是单点突破，而是三层对齐。

七、文档与教程：从 29 个示例到 34 个示例，32 个完全工作

v3.1.0 还继续补齐教程体系。

ROADMAP 中当前统计为：

• 教程示例：34 个
• 32 个完全工作
• 通过率约 94%

本次新增或补齐的关键示例包括：

• example40_declarative_oop.klx
• example41_attributes.klx
• 多个 OOP 示例：class fields、class methods、inheritance
• stdlib 示例：sysutil、jsonutil、datetime、regex
• lambda、enum、string ops 等示例补充

这件事值得强调。

很多语言项目文档里的示例是"概念示例"，并不保证可运行。

但 Kylix 的 TASKS 明确写了一个原则：

每个示例必须 kylix build + go run 全程无错，不允许"仅供参考"的示例进入 examples/complete-tutorial/。

这是一种很强的工程自律。

教程不是营销页，而是回归测试的一部分。

示例能跑，文档才可信；文档可信，开发者才敢学；开发者敢学，生态才可能起来。

八、当前累计状态：Kylix 已经不是"小编译器项目"了

截至 v3.1.0，ROADMAP 给出的累计数据已经非常可观：

指标	数量
Go 测试包	15+ 个，全部通过
Go 级测试	约 330+
Kylix 级 stdlib 测试	117 个，覆盖 10 模块
纯 Kylix stdlib 函数	90+
CLI 命令	19 个
教程示例	34 个，32 个完全工作
原生构建目标	5 个
WASM 目标	2 个
WASI 目标	2 个
LLVM 后端	Milestone 2 Phase 1
LLVM 测试	30 个
KylixBoot 测试	23 个
包注册中心	REST API + Web 前端

这些数字说明什么？

说明 Kylix 已经跨过了"只有 compiler demo"的阶段。

现在它同时拥有：

• 语言前端：lexer / parser / AST / typecheck
• Go 后端：成熟 fallback
• LLVM 后端：native binary 路线
• WASM / WASI：WebAssembly 路线
• 标准库：90+ 纯 Kylix 函数
• IDE：LSP、补全、hover、诊断、rename 等
• 工具链：test、bench、doc、fmt、repl、package manager
• 生态基础设施：registry、publish、web frontend
• 应用框架：KylixBoot

这已经是一个完整语言生态的雏形。

v3.1.0 的 KylixBoot，让这个生态开始有了"写应用"的中心。

九、v3.2 展望：真正的声明式 KylixBoot 即将开始

v3.1.0 最有意思的地方，是它很明显在为 v3.2 铺路。

ROADMAP 中 v3.2 的定位是：

自动路由注册 + ORM 注解 + LLVM Milestone 2 Phase 2/3

具体任务分为几类。

9.1 P0：注解处理器自动装配

v3.1 已经有：

• KylixBoot runtime
• 注解 AST
• Parser 支持
• LSP declarations

但还缺最关键的一步：把注解和运行时连接起来。

v3.2 要做：

• 扫描 [Controller('/path')] 类
• 识别 [Get] / [Post] / [Put] / [Delete]
• 合成完整路由路径
• 自动生成 boot.GET(...) 注册代码
• [Inject] 字段生成 DI Resolve
• [Component] / [Service] 自动注册
• 对参数缺失、重复路径给出编译期诊断

这将决定 KylixBoot 能否从"类 Spring Boot 的 API"真正变成"类 Spring Boot 的开发体验"。

9.2 P0：ORM 注解

v3.2 还计划 ORM 注解：

• [Entity('table_name')]
• [Column('col')]
• [PrimaryKey]
• [AutoIncrement]
• [Repository]
• [Query('SELECT ...')]
• 自动迁移 SQL

如果这部分做成，Kylix 将拥有一个非常完整的后端开发故事：

复制代码

[Entity('users')]
type
  TUser = class
    [PrimaryKey]
    Id: Integer;

    [Required, Email]
    Email: String;
  end;

[Repository]
type
  TUserRepository = class
    function FindById(id: Integer): TUser;
  end;

再配合 Controller 注解，KylixBoot 就会从运行时框架变成全栈后端框架。

9.3 P1：LLVM 接口与泛型

LLVM Milestone 2 接下来要补：

• 接口 fat pointer：{ ptr vtable, ptr data }
• 每个接口方法的 thunk
• obj is IFoo / obj as IFoo
• 泛型单态化：TBox<Integer>、TBox<String> 生成独立类型/函数
• AST 克隆 + 类型参数替换

这两项都很难，但它们是 Kylix 从"LLVM 可用子集"走向"LLVM 完整语言后端"的关键。

尤其是泛型单态化。

Kylix 当前已经在 Go 后端拥有泛型叙事，但 LLVM 后端要真正独立，必须拥有自己的泛型展开策略。

9.4 P3：残留 Bug

v3.1 之后仍有两个明确残留问题：

• KLX-G01：example21_generic_class 运行时异常
• KLX-M01：example33_use_module 多文件 unit 编译路径问题

这两个问题也很关键。

泛型与多文件模块，是大型项目绕不开的基本能力。v3.2 如果要支撑更完整的 KylixBoot / ORM / Repository 模型，这两个坑迟早必须填。

十、我的判断：v3.1.0 是 Kylix "应用时代"的序章

如果用一句话评价 v3.1.0，我会说：

它不是 Kylix 最大的一次版本更新，但它可能是 Kylix 走向真实应用开发最关键的一次转向。

v3.0.0-alpha 很震撼，因为 LLVM、WASI、Registry 都是大词。

但大词之后，项目最需要的是落地。

v3.1.0 做的正是落地：

• 用 KylixBoot 把 Web 应用模型立起来
• 用注解语法把声明式元编程入口打开
• 用五个编译器修复把真实代码路径打通
• 用 LLVM 数组与优化让 native 后端继续前进
• 用教程示例把"能跑"变成"可学"

这不是一次单纯的 feature release，而是一次方向校准。

Kylix 的路线越来越清晰：

1. 短期：Go 后端继续作为稳定 fallback，KylixBoot 在其上快速形成应用开发体验
1. 中期：注解处理器、ORM、安全、校验、包注册中心部署，形成后端生态闭环
1. 长期：LLVM 后端逐步补齐接口、泛型、异常、运行时，最终走向 v4.0 的独立 runtime

这条路线的优势是稳。

它没有为了"脱离 Go"而过早抛弃 Go 后端，也没有为了"框架体验"而忽略 LLVM 后端，更没有为了"语法现代"而放弃 Pascal 的清晰性。

Kylix 在做一件更难但更正确的事情：

一边保留可用的工程路径，一边建设独立的语言未来。

结语：承上启下的 v3.1.0，值得写成第二十六篇

第二十五篇的关键词是"架构突破"。

第二十六篇的关键词，我认为应该是"应用框架"。

v3.1.0 让 Kylix 不再只是展示"我能编译到哪里"，而是开始展示"我能用来构建什么"。

KylixBoot 的出现，让 Kylix 有了面向后端应用的骨架；注解语法的加入，让未来的声明式开发成为可能；五个编译器修复，让语言特性从文档回到现实；LLVM 数组与优化，则继续证明 Kylix 没有忘记自己要成为独立编译型语言的长期目标。

所以，v3.1.0 的价值不在于它完成了全部愿景。

恰恰相反，它的价值在于：

它把 v3.0 打开的所有方向，第一次拧成了一条清晰的主线。

这条主线就是：

现代 Pascal 语法 + Spring Boot 式应用框架 + 多后端编译能力 + 自举标准库 + 逐步独立的 LLVM runtime。

如果 v3.0.0-alpha 是 Kylix 迈出舒适区的第一步，那么 v3.1.0 就是它开始搭建新家的第一块梁。

下一篇，我们应该重点关注 v3.2：

• 注解是否真正驱动路由注册？
• ORM 注解能否接通数据库开发？
• LLVM 接口与泛型能否进入可用阶段？
• 包注册中心能否部署到 kylix.top/packages？

如果这些目标如期推进，Kylix 将不再只是"一个很有潜力的语言项目"。

它会开始变成一个真正能写应用、能建生态、能走向生产级的现代 Pascal 平台。

而 v3.1.0，就是这条路上的关键转折点。

Kylix v3.1.0 深度解析：从架构突破到应用框架

开篇：第二十六篇，Kylix 开始从"能生成什么"转向"能构建什么"

一、版本总览：从 v3.0.0-alpha 到 v3.1.0，8 个提交补齐 4 条主线

二、KylixBoot：Kylix 的应用框架雏形终于出现

2.1 KylixBoot 提供了什么

2.2 DI 容器：从工具函数走向应用组织方式

2.3 23 个测试：框架不是 PPT，而是可验证模块

三、注解语法：v3.1 先铺轨，v3.2 才是列车进站

3.1 AST 层新增 ast.Attribute

3.2 为什么注解是 KylixBoot 的"第二发动机"

四、五个编译器修复：v3.1.0 真正可贵的是"打通真实开发阻塞点"

4.1 KLX-C01：var p: TClass 不再生成 interface{}

4.2 KLX-C02：字符串插值恢复为现代语言基本体验

4.3 KLX-C03：lambda / 匿名函数返回类型不再丢失

4.4 KLX-C04：match 语句 codegen 不再生成无效 Go

4.5 KLX-C05：uses 符号注入，解锁 40+ stdlib 函数

五、LLVM Milestone 2 Phase 1：数组与优化让原生后端走出玩具阶段

5.1 静态数组：array[1..N] of T → [N x T]

5.2 动态数组：array of T → slice struct

5.3 编译期常量求值：数组大小不能只靠字面量

5.4 --llvm-opt=0/1/2/3：原生后端开始进入优化阶段

5.5 测试增长：LLVM 测试从 24 到 30

六、和之前版本相比，v3.1.0 的主题变了：从工具链、性能、架构，到应用开发

七、文档与教程：从 29 个示例到 34 个示例，32 个完全工作

八、当前累计状态：Kylix 已经不是"小编译器项目"了

九、v3.2 展望：真正的声明式 KylixBoot 即将开始

9.1 P0：注解处理器自动装配

9.2 P0：ORM 注解

9.3 P1：LLVM 接口与泛型

9.4 P3：残留 Bug

十、我的判断：v3.1.0 是 Kylix "应用时代"的序章

结语：承上启下的 v3.1.0，值得写成第二十六篇

3.1 AST 层新增 `ast.Attribute`

4.1 KLX-C01：`var p: TClass` 不再生成 `interface{}`

4.4 KLX-C04：`match` 语句 codegen 不再生成无效 Go

4.5 KLX-C05：`uses` 符号注入，解锁 40+ stdlib 函数

5.1 静态数组：`array[1..N] of T` → `[N x T]`

5.2 动态数组：`array of T` → slice struct

5.4 `--llvm-opt=0/1/2/3`：原生后端开始进入优化阶段