发布时间2026-06-29项目astra-zhao/kylix[1]版本v3.3.0GA与 v3.2.0 同日双版发布2026.06.28 — 2026.06.29里程碑KylixBoot 从注解骨架走向工业完整——请求体绑定、JWT 认证、OpenAPI 3.1 自动生成三大缺口一次性补齐类型检查器 MVP 完整落地包管理器与编译器彻底打通。一、写在第三十篇之前从自举到生产级 Web 框架的整条曲线这是 Kylix 项目追踪系列的第三十篇——一个值得停下来回望的整数节点。让我把过去 29 篇文章追踪过的关键节点串起来做一个 30 秒鸟瞰阶段版本里程碑1 ~ 7 篇v0.x → v1.0.2词法/语法/类型/泛型/异常/类/接口Pascal → Go 转译器走通8 ~ 14 篇v1.1 → v1.5.0字符串插值、Variant、动态数组、单元文件、自举成功 包管理器15 ~ 18 篇v2.xLSP、REPL、增量编译55× 加速、stdlib 大幅扩张19 ~ 23 篇v3.0-alphaWASI、LLVM 后端 M1、HTTP 客户端、httpclient24 ~ 27 篇v3.1.x接口验证、真泛型、KylixBoot 框架运行时核心28 篇v3.2.0-devKylixBoot 注解栈完整路由 / DI / 校验 / 安全 / ORM29 篇v3.2.0LLVM M2 收官 stdlib Phase 6 Registry 部署脚手架30 篇本篇v3.3.0Body 绑定 JWT OpenAPI 类型检查器 包管理器集成如果说前 28 篇是 Kylix从无到有的搭建过程第 29 篇是 Kylix 把v3.2.0 这个功能完整的大版本打包发布的一夜那么本篇——第 30 篇——记录的就是这个项目向生产级 Web 框架迈出的关键一步KylixBoot 不再只是一个能跑的注解框架它现在能编译时安全地绑定请求体、签发与校验 JWT、并从注解直接生成符合 OpenAPI 3.1 标准的 API 文档。这三件事是任何现代后端框架——Spring Boot、FastAPI、NestJS、Quarkus——的标配。在 v3.3.0 之前KylixBoot 的注解只能装配路由和拦截器在 v3.3.0 之后它已经具备和上述框架同台竞争的最小可用面。二、为什么 v3.3.0 同日跟着 v3.2.0 发布读 CHANGELOG 的时候你会注意到一个有趣的细节## v3.3.0 (2026-06-29) — Body Binding JWT OpenAPI ## v3.2.0 (2026-06-29) — Annotation Stack LLVM M2 stdlib Phase 6两个大版本同一天发布。这是巧合吗不是。回到第 29 篇文章的最后一段——我当时写道v3.2.0 正式 release tag 很可能在几天内推出。事实是团队几乎零等待地把 v3.2.0 打了 tag然后立刻进入 v3.3.0 的开发——这本身又是一个 24 小时级别的高速冲刺。为什么不把这些功能塞进 v3.2.0因为 v3.2.0 已经是一个完整的、闭环的、有清晰主题的版本注解栈 LLVM M2 收官 stdlib Phase 6。继续往里塞 Body 绑定、JWT、OpenAPI会让发布说明变得臃肿、focus 涣散。Kylix 团队的版本管理观清晰可见• 一个 minor 版本v3.X.0 一个清晰的主题• 主题闭环 → 发布 → 立刻开始下一个主题• 不堆功能、不拖发布、不让在做的事情模糊已发布的事情这是成熟开源项目的特征。三、[Body(TEntity)]让 POST/PUT 变得声明式安全如果要在 v3.3.0 里挑一个最具代表性的新功能那就是[Body]注解。3.1 v3.3.0 之前你必须手写的模板代码来看看在 v3.2.0 时代写一个带请求体校验的 POST 路由是什么体验[Post(/users)] function CreateUser(req: TRequest): TResponse; var body: TCreateUser; begin // 1. 反序列化 if not BootReadJSON(req, body) then exit(BootJSON(400, record error : invalid JSON; end)); // 2. 业务校验 if not body.IsValid() then exit(BootJSON(400, body.Validate())); // 3. 真正的业务逻辑被前面 N 行模板代码淹没 result : BootText(200, created); end;每一个 POST/PUT 路由都要重复这套模板。这是任何手写 Web 框架都绕不开的样板炎症。3.2 v3.3.0 的声明式写法[Post(/users)] [Body(TCreateUser)] function CreateUser(req: TRequest): TResponse; begin result : BootText(200, created); end;三行注解零行模板代码。但请注意——模板代码并没有消失它是被编译器在编译期自动注入的// 编译器自动生成 stdlib.BootPOST(/api/users, func(req *stdlib.BootRequest) *stdlib.BootResponse { var __body TCreateUser if err : stdlib.BootReadJSON(req, __body); err ! nil { return stdlib.BootJSON(400, map[string]string{error: invalid JSON}) } if !__body.IsValid() { return stdlib.BootJSON(400, __body.Validate()) } return __kylix_ctrl_TUserController.CreateUser(req) })3.3 这个设计的三个工程意义第一编译期生成 vs 运行时反射Spring Boot 的RequestBody是运行时反射 注解扫描FastAPI 的 Pydantic 模型是运行时类型校验。两者都付出了显著的运行时开销。Kylix 选择了编译期注入没有反射、没有运行时类型查表生成的 Go 代码和你手写的一模一样。这是 Pascal 这种强类型 编译时已知一切的天然优势。第二与[Required]/[Email]/[Min]/[MaxLen]完美链式TCreateUser上的字段校验注解v3.2.0 引入会自动被编译器生成IsValid()/Validate()方法。[Body]注解恰好把这些方法接进了请求处理管道type TCreateUser class [Required, Email] Email: String; [Required, MinLen(8)] Password: String; end;写好这个类所有用[Body(TCreateUser)]的路由都会自动获得 Email 格式 密码长度校验错误自动返回 400 错误明细。校验逻辑与路由完全解耦。第三错误码迁移KLX214 取代 KLX301CHANGELOG 里有一行很容易被忽略的修复Error code fix—ErrBodyBindingmoved fromKLX301(collision) toKLX214.之前ErrBodyBinding被定义为 KLX301但 KLX301 已经被ErrMissingMethod占用——这是一个编码冲突会让两类完全不同的错误显示同一个错误码对用户极度不友好。v3.3.0 把它迁移到 KLX214——回到 KLX207–KLX213 这条KylixBoot 注解诊断码的连续区段。这是一个框架契约一致性的修复所有注解相关的诊断码现在统一在 KLX207–KLX214。四、JWT HS256从零到一的 Web 安全闭环v3.2.0 引入了[Authenticated]注解但它只是一个接口契约——具体的token 是什么、怎么签、怎么验需要开发者通过BootRegisterAuthValidator自己实现。这是个明智的解耦但对绝大多数 Web 项目而言开发者真正需要的是开箱即用的 JWT。v3.3.0 把这块补上了。4.1 一个新的标准库模块uses jwtuses boot, jwt; begin // 一行接入 [Authenticated] BootRegisterJwtAuth(my-secret); // 签发 token var token : JwtSign(my-secret, user42, 3600, nil); // 验证 token var claims : JwtVerify(my-secret, token); WriteLn(JwtSubject(claims)); // user42 end.5 个核心函数函数用途JwtSign(secret, subject, expiresIn, claims)HS256 签名生成 tokenJwtVerify(secret, token)验证签名 过期时间返回 claimsJwtSubject(claims)提取标准 sub 字段JwtGetString(claims, key)读取自定义字符串 claimJwtGetInt(claims, key)读取自定义整数 claim4.2 关键设计BootRegisterJwtAuth一行接入CHANGELOG 里这句话值得反复读BootRegisterJwtAuth(secret)wires JWT validation into the[Authenticated]guard with one call.这意味着 KylixBoot 把两件原本割裂的事情接成了一条直线[Authenticated] 注解 ─┐ ├──→ BootEnforceAuth ──→ AuthValidator 接口 │ BootRegisterJwtAuth ──┘ (默认实现JWT HS256 校验)开发者完全不用知道[Authenticated]背后调用的是BootEnforceAuth、BootRegisterAuthValidator、JWT 签名校验逻辑——他只需要BootRegisterJwtAuth(secret); // 启动时一行所有标了[Authenticated]的路由就自动进入 JWT 保护状态。这就是约定优于配置的极致体现也是 Spring Boot / FastAPI 之所以被称为开发者友好框架的根本原因。4.3 实现细节纯 Go stdlib零外部依赖CHANGELOG 强调了一句Pure Go stdlib implementation — no external dependencies.这是一个经过深思熟虑的选择。Go 生态里有不少成熟的 JWT 库如github.com/golang-jwt/jwt引入它们可以节省工作量但代价是• 增加一个外部依赖项每个依赖都是一个潜在的供应链风险• 受制于第三方库的发版节奏和 breaking changes• 对 LLVM 后端未来要完全脱离 Go的目标埋雷Kylix 团队选择自己实现 HS256 base64url JSON claims——这一切只用 Go 标准库crypto/hmac、crypto/sha256、encoding/base64、encoding/json。代码量不大HS256 算法本身只有几十行但战略意义很大Kylix stdlib 的所有功能未来都能被 LLVM 后端无痛接入。这与 stdlib Phase 6 引入golang.org/x/crypto形成对比——bcrypt 那是真的没有简洁的纯 Go 标准库替代所以只能引入JWT 完全可以自己写那就自己写。每一个依赖都经过严格审查——这是 Kylix 整个项目的开发哲学。4.4 安全注解 JWT 完整的认证授权链把 v3.2.0 的安全注解和 v3.3.0 的 JWT 拼起来看整条认证授权链终于完整了[Controller(/api)] type TAdminController class [Get(/dashboard)] [Authenticated] // JWT 校验 function Dashboard(req: TRequest): TResponse; begin ... end; [Delete(/users/:id)] [Role(admin)] // JWT 校验 角色校验 function DeleteUser(req: TRequest): TResponse; begin ... end; end; begin BootRegisterJwtAuth(production-secret); // 一行启用 // 路由全自动 end.Spring Security 的开发者看到这段代码会愣一下——因为 Spring 等价代码需要WebSecurityConfigurerAdapter、JwtAuthenticationProvider、SecurityFilterChain、PreAuthorize、EnableMethodSecurity一整套 XML / 注解 / 配置类。而 KylixBoot 用了一个[Authenticated]注解 一行BootRegisterJwtAuth就搞定了。这不是少了功能——这是少了仪式。五、OpenAPI 3.1让代码和API 文档永不脱节这是 v3.3.0 里最具长期价值的功能。5.1 文档与代码永远脱节的痛苦任何写过 REST API 的工程师都体验过这种痛苦• 接口改了Swagger 文档没改 → 前端按旧文档调用线上炸了• Swagger 文档改了但实现没改 → 前端按新文档调用404• 接口和文档都改了但忘了改测试用例 → CI 通过集成爆炸根本原因是文档与代码是两份独立维护的事实。手工同步必然脱节。5.2 v3.3.0 的解法从注解直接生成 OpenAPI 3.1kylix doc --openapi --title My API --api-version 1.0.0 api.klx输出docs/api/openapi.yamlopenapi: 3.1.0 info: title: My API version: 1.0.0 paths: /api/v1/users: post: operationId: TUserController_CreateUser requestBody: required: true content: application/json: schema: $ref: #/components/schemas/TCreateUser responses: 200: description: OK components: schemas: TCreateUser: type: object required: [Email, Password] properties: Email: type: string format: email Password: type: string minLength: 8 securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT注意几个关键映射Kylix 注解OpenAPI 字段[Controller(/api/v1)][Post(/users)]paths→/api/v1/users→post[Body(TCreateUser)]requestBody.content.application/json.schema.$ref[Entity][Required]/[Email]/[Min]等components.schemas.TCreateUser[Authenticated]/[Role]components.securitySchemes.BearerAuth5.3 这意味着什么第一单一事实来源代码就是文档。改代码 → 重新跑kylix doc --openapi→ 文档自动更新。前端、QA、外部合作方拿到的 OpenAPI 永远和真实运行的服务对齐。第二零运行时开销FastAPI 的 OpenAPI 是运行时生成的——服务启动时反射扫描所有路由构造 schema。Kylix 是编译期生成——不需要服务在跑纯静态分析.klx源文件就能产出文档。第三与 Kylix 路径参数语法的语义桥接CHANGELOG 里有一句话自动转换 Kylix 路径参数:id→{id}并生成 Bearer 认证方案。Kylix 用 Pascal 风格的:idOpenAPI 用{id}——kylix doc --openapi在生成时自动转换。这是一个小细节但说明设计者真正理解 OpenAPI 规范、并尊重它的约定。5.4 接下来可以做什么只要openapi.yaml生成出来了整个 OpenAPI 生态都可以为你所用•swagger-ui→ 直接渲染交互式文档•openapi-generator→ 一键生成 TypeScript / Python / Java 客户端 SDK•prism/dredd→ 用 OpenAPI 做 Contract Test•postman→ 一键导入接口集合Kylix 第一次实现了写 Kylix 后端 生成 TypeScript 前端 SDK的端到端闭环。5.5 已知限制嵌套对象 schemaCHANGELOG 坦诚地写OpenAPI 生成器不支持嵌套对象 schema仅顶层属性这是一个有意识的 MVP 边界——大多数 REST API 的请求体不会有超过两层嵌套user 里嵌 address 这种先把 80% 的场景做完美剩下的嵌套场景作为 v3.4 的迭代。这种克制的产品节奏和之前 LLVM M2 留出的延期清单是一脉相承的。六、包管理器与编译器的最后一公里打通这是一项看上去不起眼但开发体验上杀手级的改进。6.1 v3.3.0 之前的尴尬kylix add github.com/user/http # ✅ 文件被下载到 packages/http/http.klx # ❌ 但 kylix build main.klx 找不到这个文件 # 你必须手动 kylix build main.klx packages/http/http.klx # 或者配置一些复杂的 import 路径包管理器能加包但编译器不知道。这种两个工具各干各的的状态会让用户极度困惑——我都kylix add了为什么uses http还是报错6.2 v3.3.0 的修复CompileProject现在自动发现packages/*/目录下的所有.klx文件kylix add github.com/user/http # 1. 添加依赖 # kylix.toml 自动更新, packages/http/http.klx 自动创建 kylix build main.klx # 2. 编译 # 编译器自动扫描 packages/*/, http.klx 自动加入编译列表 # main.klx 里 uses http; 直接可用6.3 去重逻辑避免重复编译CHANGELOG 里提到一个 bug 修复包管理器文件重复编译CompileProject现在对PackageSearchDirs和显式传入的文件去重这是真实的工程细节——如果用户同时kylix build main.klx packages/http/http.klx手动传入和packages/*自动扫描http.klx就会被编译两次导致符号重复定义。新版本用map[string]bool去重无论用户怎么传都只编译一次。6.4 测试覆盖packages_test.go上线新增的packages_test.go验证• 包管理器能正确发现packages/*子目录• 显式传入与自动扫描结合时的去重逻辑• 多层嵌套包的处理CHANGELOG 这一段读起来波澜不惊——但要知道过去这块代码的测试覆盖率是0详见 CLAUDE.md 列出的已知技术债 3.1。现在pkg/pkgmgr终于有了自己的测试这是 Kylix 工程化进程的又一块拼图归位。七、类型检查器 MVP862 行的质量护栏虽然 CHANGELOG 标注为Type checker already complete——意思是这部分在内部其实更早就在做了——但它第一次在 v3.3.0 被作为发布亮点公开。7.1pkg/compiler/typecheck.go覆盖的检查✅ 未声明变量/函数引用 ✅ 函数调用参数数量不匹配 ✅ 赋值类型兼容性 ✅ 泛型约束验证 ✅ 接口实现验证含继承链 ✅ 类型别名循环检测862 行代码 7 个测试场景— 这是把 Kylix 的编译期质量护栏从原本的语法层 代码生成层扩展到了完整的语义层。7.2 一个具体例子泛型约束验证type IComparable interface function CompareTo(other: T): Integer; end; type TBox class // ← T 必须实现 IComparable Value: T; end; var box: TBox; // ❌ Integer 不实现 IComparable // 编译期立刻报错无需等到代码生成失败这种检查的关键价值不是找到 bug——而是把错误前移。以前类似的错误可能只能在生成 Go 代码、Go 编译器报错、用户翻译错误信息回 Kylix 上下文才能定位现在 Kylix 直接在源码层面报错错误信息精准、行号精准、上下文精准。7.3 与Kylix 层错误报告v3.1.x的呼应第 24 篇文章里我曾详细介绍过 Kylix v3.1.x 的Kylix 层错误报告——把 Go 编译器的报错翻译回 Kylix 上下文。类型检查器是这套设计的延伸能在 Kylix 层就抓住的错误不要让它流到 Go 层再被抓。两者结合形成了双层防护1. 第一道类型检查器前置主动2. 第二道Go 错误翻译器后置兜底这种防御纵深的工程实践是任何产品级编译器都必须有的。八、性能改进增量编译被实测验证CHANGELOG 给出了具体数字场景编译时间加速比冷编译 10 个单元文件4.2ms1.0x热编译全部缓存命中1.1ms3.7x部分缓存修改 1 个文件1.2ms3.6x关键观察v1.5.0 时代我们说增量编译有 55× 加速——那是基于一个更大的项目基准。这次的数字看起来温和是因为基准换成了 10 个单元的小型项目。但更重要的是这是第一次有performance_test.go这种正式的基准测试。之前55× 加速是手测的现在变成了 CI 可以跑的基准。性能从此可被回归保护——任何一次代码改动如果让编译性能退化CI 立刻报警。这是真正的工程化。九、版本演进的承上启下让我们把视野拉远看 v3.2.0 和 v3.3.0 的关系。9.1 v3.2.0注解栈的骨架v3.2.0 完成了什么[Controller] ← 路由 [Service] ← DI [Required] ← 校验 [Authenticated]← 安全接口契约 [Entity] ← ORM这是一套完整的注解骨架——所有注解、所有诊断码、所有运行时支撑全部就位。但这套骨架还缺少肌肉•[Authenticated]有契约但没有默认实现用户必须自己写 AuthValidator• POST/PUT 路由能写但没有声明式 Body 绑定• 注解信息全在编译器里但没法导出给外部世界前端、文档、API gateway9.2 v3.3.0把肌肉长到骨架上v3.3.0 一次性补齐了三块关键肌肉v3.2.0 骨架 → v3.3.0 添加的肌肉 ───────────────────────────────────────────── [Authenticated] 契约 → JWT HS256 默认实现 BootRegisterJwtAuth [Post] / [Put] → [Body(T)] 声明式 Body 绑定 注解信息内部 → OpenAPI 3.1 自动导出v3.2.0 v3.3.0 一个完整的 KylixBoot 框架。从这两个版本开始KylixBoot 可以宣称自己是一个现代化的、声明式的、编译期安全的 Pascal 后端 Web 框架。9.3 一张表对比v3.2.0 vs v3.3.0维度v3.2.0v3.3.0注解栈完整骨架骨架 Body 绑定肌肉认证[Authenticated]契约 JWT 默认实现文档无OpenAPI 3.1 自动生成类型检查编译时报错基础 862 行类型检查器 MVP包管理工具能加包工具与编译器打通LLVM 后端M2 完整不变无新增stdlib13 模块14 模块jwt教程42/4245/453 新示例错误码KLX207–213KLX214KLX301 冲突修复包测试pkg/pkgmgr零覆盖packages_test.go性能测试手测 55×performance_test.go自动基准十、深度分析v3.3.0 体现的产品成熟度把 v3.3.0 单独拎出来读一遍 CHANGELOG你会发现它和之前所有 Kylix 版本都不太一样10.1 这是第一个被产品需求驱动的版本之前的版本主题大多是编译器能力——LLVM 后端、增量编译、泛型、接口验证、注解栈。开发者视角的我希望编译器能做什么。v3.3.0 的主题完全不同——它讨论的是 Body 绑定、JWT、OpenAPI、包管理器集成——用户视角的我希望写 Web 服务时能少做什么。这是 Kylix 项目第一次明显地从我有什么转向用户要什么。这种转向通常发生在编译器项目走向成熟的某个临界点——而 v3.3.0 看起来就是那个临界点。10.2 错误码冲突的修复说明了什么ErrBodyBinding从 KLX301 迁移到 KLX214 的修复技术上很微小但它的存在本身说明 Kylix 团队在做一件事审视并维护错误码体系的一致性。成熟的工业级编译器GCC、Clang、Rustc都有错误码作为产品契约的意识——错误码一旦发布就是用户文档的一部分错误码冲突是必须修复的契约违反。v3.3.0 主动做这件事说明 Kylix 已经把自己当成一个长期维护的产品而不是一个一直在改的实验。10.3 已知限制的坦诚CHANGELOG 末尾列出了两条已知限制•CompileFile单文件模式不自动解析uses依赖需手动传入所有文件或使用项目模式• OpenAPI 生成器不支持嵌套对象 schema仅顶层属性这种坦诚是开源项目的最高级礼貌。它告诉用户• 我们知道什么能用、什么不能用• 你不会在生产环境踩到我们没说过的坑• 如果你正好需要这个被列出的限制请等 v3.4 或者自己 PR这是 Linus Torvalds 在 Linux 邮件列表里反复强调的态度Never silently break userspace.永远不要悄悄地破坏用户空间10.4 向后兼容的承诺CHANGELOG 升级指南第一句话从 v3.2.0 升级到 v3.3.0 无需修改现有代码。新功能全部向后兼容。这是一个强承诺。在一个仍处于 v3.x 的快速迭代项目里能做到这一点说明• API 设计的内聚性强新功能不需要改既有 API• 错误码扩展而不是替换KLX214 是新加的KLX213 之前的全保留• 注解语法是叠加式的[Body]加在[Post]旁边不替换[Post]向后兼容是工业级编程语言的硬指标。Kylix 在 v3.3.0 兑现了这个指标。十一、对竞争格局的新定位如果用一张表对比当下主流后端框架的注解能力v3.3.0 的 KylixBoot 已经处在什么位置能力Spring Boot (Java)FastAPI (Python)NestJS (TS)KylixBoot (Kylix)路由注解✅RestController✅app.get✅Controller✅[Controller]/[Get]DI 自动装配✅Autowired✅Depends()✅Injectable✅[Inject]字段校验✅Valid JSR-380✅ Pydantic✅class-validator✅[Required]/[Email]Body 绑定✅RequestBody✅ Pydantic 模型✅Body()✅v3.3.0[Body(T)]JWT 内置⚠️ 需 Spring Security⚠️ 需 PyJWT⚠️ 需 nestjs/jwt✅v3.3.0uses jwtOpenAPI 生成✅ springdoc✅ 内置运行时✅ nestjs/swagger✅v3.3.0编译期生成ORM 注解✅ JPAEntity⚠️ SQLAlchemy 单独✅ TypeORM✅[Entity]/[Repository]编译期 vs 运行时运行时反射运行时运行时编译期生成代码KylixBoot 在 v3.3.0 之后第一次在功能矩阵上对齐了主流 Web 框架。它的差异化优势1.编译期生成 vs 运行时反射— 零反射开销启动即满速2.强类型 Pascal— 比 Python / JS 的弱类型更早抓 bug3.多后端编译— 同一份 Kylix 代码能编译到 Go binary、WASI、LLVM native4.完整的工具链一体化— kylix 一条 CLI 命令完成 build / test / fmt / doc / publish十二、统计快照v3.3.0 GA 时刻指标v3.2.0昨天v3.3.0今天变化教程示例42/4245/453Body / JWT / OpenAPIstdlib 模块1314jwt1KLX 诊断码上限KLX213KLX2141修复冲突包测试0packages_test.go上线新增类型检查器内部公开 862 行 7 测试MVP 完整性能基准测试手测performance_test.go自动化包管理器集成度部分完全打通✅OpenAPI 自动生成❌✅ 3.1 标准新能力JWT 内置❌✅ HS256新能力Body 绑定手写✅ 注解新能力Go 测试通过率16 包全通16 包全通稳向后兼容性—✅ 100%兑现十三、下一步v3.4 / v4.0 的两条线索13.1 v3.4 / v3.5 的可能方向CHANGELOG 没明确说但从这次的已知限制可以推测•嵌套对象 schema 的 OpenAPI 生成——补齐复杂请求体场景•CompileFile单文件模式的 uses 依赖解析——让单文件场景也自动化•JWT 算法扩展RS256 / ES256HS256 之外的非对称算法•KylixBoot 的更多默认中间件限流、缓存、CSRF、压缩•OpenAPI 反向从 yaml 生成 Kylix stub— Schema-First 开发流13.2 v4.0 的完全脱离 Go路径第 29 篇我详细分析过 v4.0 的核心目标——LLVM Milestone 3 KylixRT。v3.3.0 选择纯 Go stdlib 实现 JWT、不引入外部依赖是为这条路径继续清地基。每多一个外部 Go 依赖v4.0 的 LLVM 后端就多一份移植负担。按照当前节奏v4.0 的发布时间表可能比 ROADMAP 预期的 2027 年提前到 2026 年第四季度。这是非常激进的判断但看着这几周的密度并不夸张。十四、第三十篇收尾从个人 side project到准生产级语言这是 Kylix 项目追踪系列的第三十篇。我想用三句话总结过去 30 篇文章串起来的整条 Kylix 发展故事第一句从无到有。Kylix 不是一夜建成的。前 14 篇文章记录了它如何从词法分析器开始一行行写到自举成功。每一篇都意味着一个新增的语言特性、一个解决的编译器 bug、一段被攻克的实现难关。第二句从有到好。v2.x 到 v3.2.0Kylix 的工作重心从能跑转向好用——LSP、REPL、增量编译、KylixBoot 框架、注解栈、LLVM 后端、stdlib 大幅扩张。这是从原型到产品的转化。第三句从好到全。v3.3.0 是 Kylix 第一次有底气说自己全——•语言全类、接口、泛型、异常、模式匹配、属性、字符串插值、async/await现代语言特性齐备•编译全Go 后端 LLVM 后端 WASI 后端三个 target 都能生产可执行文件•生态全stdlib 14 模块 KylixBoot Web 框架 ORM 注解 JWT 认证 OpenAPI 生成 包管理器 包注册中心•工具全build / test / bench / fmt / doc / repl / lsp / publish / new一个kylix命令通吃•质量全862 行类型检查器 Kylix 层错误报告 增量编译 性能基准测试 16 包测试覆盖Kylix 已经不是一个试图实现现代 Pascal的实验项目了。它是一个准生产级编程语言。14.1 写给 Kylix 团队的话第三十篇是个里程碑但绝不是终点。从 v3.3.0 出发前方还有• v3.4 的产品化打磨• v3.5 的生态扩展• v4.0 的完全脱离 Go——KylixRT 自研运行时• 中长期的社区建设、IDE 插件、企业模板、真实项目落地每一步都比上一步更难。但 Kylix 已经证明了一件事这个团队的开发节奏、工程克制、质量意识是一流的。14.2 写给读者的话如果你是第一次读这个系列——欢迎来到第三十篇。前 29 篇构成了一个完整的现代编程语言从零到生产级的工程实录每一篇都尝试不止记录做了什么更试图回答为什么这样做和这样做意味着什么。如果你是从第一篇追到第三十篇的老读者——感谢你的陪伴。Kylix 这个项目证明了一个由人精心打磨、节奏稳健、设计克制的编程语言项目可以在不到半年时间里从原型走到准生产级。这本身就是一个值得书写的故事。14.3 三句话总结 v3.3.01.KylixBoot 完整了Body 绑定 JWT OpenAPI 三大缺口一次性补齐与 Spring Boot / FastAPI / NestJS 同台竞争的最小可用面已经成立。2.工程基建完整了类型检查器 MVP 包管理器编译器集成 性能基准测试 错误码冲突修复每一项都把 Kylix 往工业级推了一步。3.承上启下完整了v3.2.0 的注解骨架在 v3.3.0 长出了肌肉v3.3.0 的纯 Go stdlib 实现为 v4.0 的脱离 Go铺平地基。Kylix v3.3.0一个能写真正的生产级 Web 服务的 Pascal。从 v1.0 到 v3.3.0从词法分析器到 OpenAPI 自动生成30 篇文章13 个月无数行代码。下一个 30 篇见。本文是 Kylix 项目追踪系列的第三十篇基于 2026 年 6 月 29 日 v3.3.0 正式发布时的项目状态编写。附录v3.3.0 速查编译期 Body 绑定[Post(/users)] [Body(TCreateUser)] function CreateUser(req: TRequest): TResponse;JWT 一行接入uses boot, jwt; BootRegisterJwtAuth(my-secret);OpenAPI 一行生成kylix doc --openapi --title My API --api-version 1.0.0 api.klx包管理器自动集成kylix add http kylix build main.klx # packages/http/http.klx 自动被发现完整 CHANGELOGhttps://github.com/astra-zhao/kylix/blob/main/CHANGELOG.mdRelease Noteshttps://github.com/astra-zhao/kylix/blob/main/RELEASE\_v3.3.0.md官方网站kylix.top[2]引用链接[1]astra-zhao/kylix:https://github.com/astra-zhao/kylix[2]kylix.top:https://kylix.top
Kylix 项目追踪（三十）：v3.3.0 正式发布！Body 绑定 + JWT + OpenAPI
发布时间2026-06-29项目astra-zhao/kylix[1]版本v3.3.0GA与 v3.2.0 同日双版发布2026.06.28 — 2026.06.29里程碑KylixBoot 从注解骨架走向工业完整——请求体绑定、JWT 认证、OpenAPI 3.1 自动生成三大缺口一次性补齐类型检查器 MVP 完整落地包管理器与编译器彻底打通。一、写在第三十篇之前从自举到生产级 Web 框架的整条曲线这是 Kylix 项目追踪系列的第三十篇——一个值得停下来回望的整数节点。让我把过去 29 篇文章追踪过的关键节点串起来做一个 30 秒鸟瞰阶段版本里程碑1 ~ 7 篇v0.x → v1.0.2词法/语法/类型/泛型/异常/类/接口Pascal → Go 转译器走通8 ~ 14 篇v1.1 → v1.5.0字符串插值、Variant、动态数组、单元文件、自举成功 包管理器15 ~ 18 篇v2.xLSP、REPL、增量编译55× 加速、stdlib 大幅扩张19 ~ 23 篇v3.0-alphaWASI、LLVM 后端 M1、HTTP 客户端、httpclient24 ~ 27 篇v3.1.x接口验证、真泛型、KylixBoot 框架运行时核心28 篇v3.2.0-devKylixBoot 注解栈完整路由 / DI / 校验 / 安全 / ORM29 篇v3.2.0LLVM M2 收官 stdlib Phase 6 Registry 部署脚手架30 篇本篇v3.3.0Body 绑定 JWT OpenAPI 类型检查器 包管理器集成如果说前 28 篇是 Kylix从无到有的搭建过程第 29 篇是 Kylix 把v3.2.0 这个功能完整的大版本打包发布的一夜那么本篇——第 30 篇——记录的就是这个项目向生产级 Web 框架迈出的关键一步KylixBoot 不再只是一个能跑的注解框架它现在能编译时安全地绑定请求体、签发与校验 JWT、并从注解直接生成符合 OpenAPI 3.1 标准的 API 文档。这三件事是任何现代后端框架——Spring Boot、FastAPI、NestJS、Quarkus——的标配。在 v3.3.0 之前KylixBoot 的注解只能装配路由和拦截器在 v3.3.0 之后它已经具备和上述框架同台竞争的最小可用面。二、为什么 v3.3.0 同日跟着 v3.2.0 发布读 CHANGELOG 的时候你会注意到一个有趣的细节## v3.3.0 (2026-06-29) — Body Binding JWT OpenAPI ## v3.2.0 (2026-06-29) — Annotation Stack LLVM M2 stdlib Phase 6两个大版本同一天发布。这是巧合吗不是。回到第 29 篇文章的最后一段——我当时写道v3.2.0 正式 release tag 很可能在几天内推出。事实是团队几乎零等待地把 v3.2.0 打了 tag然后立刻进入 v3.3.0 的开发——这本身又是一个 24 小时级别的高速冲刺。为什么不把这些功能塞进 v3.2.0因为 v3.2.0 已经是一个完整的、闭环的、有清晰主题的版本注解栈 LLVM M2 收官 stdlib Phase 6。继续往里塞 Body 绑定、JWT、OpenAPI会让发布说明变得臃肿、focus 涣散。Kylix 团队的版本管理观清晰可见• 一个 minor 版本v3.X.0 一个清晰的主题• 主题闭环 → 发布 → 立刻开始下一个主题• 不堆功能、不拖发布、不让在做的事情模糊已发布的事情这是成熟开源项目的特征。三、[Body(TEntity)]让 POST/PUT 变得声明式安全如果要在 v3.3.0 里挑一个最具代表性的新功能那就是[Body]注解。3.1 v3.3.0 之前你必须手写的模板代码来看看在 v3.2.0 时代写一个带请求体校验的 POST 路由是什么体验[Post(/users)] function CreateUser(req: TRequest): TResponse; var body: TCreateUser; begin // 1. 反序列化 if not BootReadJSON(req, body) then exit(BootJSON(400, record error : invalid JSON; end)); // 2. 业务校验 if not body.IsValid() then exit(BootJSON(400, body.Validate())); // 3. 真正的业务逻辑被前面 N 行模板代码淹没 result : BootText(200, created); end;每一个 POST/PUT 路由都要重复这套模板。这是任何手写 Web 框架都绕不开的样板炎症。3.2 v3.3.0 的声明式写法[Post(/users)] [Body(TCreateUser)] function CreateUser(req: TRequest): TResponse; begin result : BootText(200, created); end;三行注解零行模板代码。但请注意——模板代码并没有消失它是被编译器在编译期自动注入的// 编译器自动生成 stdlib.BootPOST(/api/users, func(req *stdlib.BootRequest) *stdlib.BootResponse { var __body TCreateUser if err : stdlib.BootReadJSON(req, __body); err ! nil { return stdlib.BootJSON(400, map[string]string{error: invalid JSON}) } if !__body.IsValid() { return stdlib.BootJSON(400, __body.Validate()) } return __kylix_ctrl_TUserController.CreateUser(req) })3.3 这个设计的三个工程意义第一编译期生成 vs 运行时反射Spring Boot 的RequestBody是运行时反射 注解扫描FastAPI 的 Pydantic 模型是运行时类型校验。两者都付出了显著的运行时开销。Kylix 选择了编译期注入没有反射、没有运行时类型查表生成的 Go 代码和你手写的一模一样。这是 Pascal 这种强类型 编译时已知一切的天然优势。第二与[Required]/[Email]/[Min]/[MaxLen]完美链式TCreateUser上的字段校验注解v3.2.0 引入会自动被编译器生成IsValid()/Validate()方法。[Body]注解恰好把这些方法接进了请求处理管道type TCreateUser class [Required, Email] Email: String; [Required, MinLen(8)] Password: String; end;写好这个类所有用[Body(TCreateUser)]的路由都会自动获得 Email 格式 密码长度校验错误自动返回 400 错误明细。校验逻辑与路由完全解耦。第三错误码迁移KLX214 取代 KLX301CHANGELOG 里有一行很容易被忽略的修复Error code fix—ErrBodyBindingmoved fromKLX301(collision) toKLX214.之前ErrBodyBinding被定义为 KLX301但 KLX301 已经被ErrMissingMethod占用——这是一个编码冲突会让两类完全不同的错误显示同一个错误码对用户极度不友好。v3.3.0 把它迁移到 KLX214——回到 KLX207–KLX213 这条KylixBoot 注解诊断码的连续区段。这是一个框架契约一致性的修复所有注解相关的诊断码现在统一在 KLX207–KLX214。四、JWT HS256从零到一的 Web 安全闭环v3.2.0 引入了[Authenticated]注解但它只是一个接口契约——具体的token 是什么、怎么签、怎么验需要开发者通过BootRegisterAuthValidator自己实现。这是个明智的解耦但对绝大多数 Web 项目而言开发者真正需要的是开箱即用的 JWT。v3.3.0 把这块补上了。4.1 一个新的标准库模块uses jwtuses boot, jwt; begin // 一行接入 [Authenticated] BootRegisterJwtAuth(my-secret); // 签发 token var token : JwtSign(my-secret, user42, 3600, nil); // 验证 token var claims : JwtVerify(my-secret, token); WriteLn(JwtSubject(claims)); // user42 end.5 个核心函数函数用途JwtSign(secret, subject, expiresIn, claims)HS256 签名生成 tokenJwtVerify(secret, token)验证签名 过期时间返回 claimsJwtSubject(claims)提取标准 sub 字段JwtGetString(claims, key)读取自定义字符串 claimJwtGetInt(claims, key)读取自定义整数 claim4.2 关键设计BootRegisterJwtAuth一行接入CHANGELOG 里这句话值得反复读BootRegisterJwtAuth(secret)wires JWT validation into the[Authenticated]guard with one call.这意味着 KylixBoot 把两件原本割裂的事情接成了一条直线[Authenticated] 注解 ─┐ ├──→ BootEnforceAuth ──→ AuthValidator 接口 │ BootRegisterJwtAuth ──┘ (默认实现JWT HS256 校验)开发者完全不用知道[Authenticated]背后调用的是BootEnforceAuth、BootRegisterAuthValidator、JWT 签名校验逻辑——他只需要BootRegisterJwtAuth(secret); // 启动时一行所有标了[Authenticated]的路由就自动进入 JWT 保护状态。这就是约定优于配置的极致体现也是 Spring Boot / FastAPI 之所以被称为开发者友好框架的根本原因。4.3 实现细节纯 Go stdlib零外部依赖CHANGELOG 强调了一句Pure Go stdlib implementation — no external dependencies.这是一个经过深思熟虑的选择。Go 生态里有不少成熟的 JWT 库如github.com/golang-jwt/jwt引入它们可以节省工作量但代价是• 增加一个外部依赖项每个依赖都是一个潜在的供应链风险• 受制于第三方库的发版节奏和 breaking changes• 对 LLVM 后端未来要完全脱离 Go的目标埋雷Kylix 团队选择自己实现 HS256 base64url JSON claims——这一切只用 Go 标准库crypto/hmac、crypto/sha256、encoding/base64、encoding/json。代码量不大HS256 算法本身只有几十行但战略意义很大Kylix stdlib 的所有功能未来都能被 LLVM 后端无痛接入。这与 stdlib Phase 6 引入golang.org/x/crypto形成对比——bcrypt 那是真的没有简洁的纯 Go 标准库替代所以只能引入JWT 完全可以自己写那就自己写。每一个依赖都经过严格审查——这是 Kylix 整个项目的开发哲学。4.4 安全注解 JWT 完整的认证授权链把 v3.2.0 的安全注解和 v3.3.0 的 JWT 拼起来看整条认证授权链终于完整了[Controller(/api)] type TAdminController class [Get(/dashboard)] [Authenticated] // JWT 校验 function Dashboard(req: TRequest): TResponse; begin ... end; [Delete(/users/:id)] [Role(admin)] // JWT 校验 角色校验 function DeleteUser(req: TRequest): TResponse; begin ... end; end; begin BootRegisterJwtAuth(production-secret); // 一行启用 // 路由全自动 end.Spring Security 的开发者看到这段代码会愣一下——因为 Spring 等价代码需要WebSecurityConfigurerAdapter、JwtAuthenticationProvider、SecurityFilterChain、PreAuthorize、EnableMethodSecurity一整套 XML / 注解 / 配置类。而 KylixBoot 用了一个[Authenticated]注解 一行BootRegisterJwtAuth就搞定了。这不是少了功能——这是少了仪式。五、OpenAPI 3.1让代码和API 文档永不脱节这是 v3.3.0 里最具长期价值的功能。5.1 文档与代码永远脱节的痛苦任何写过 REST API 的工程师都体验过这种痛苦• 接口改了Swagger 文档没改 → 前端按旧文档调用线上炸了• Swagger 文档改了但实现没改 → 前端按新文档调用404• 接口和文档都改了但忘了改测试用例 → CI 通过集成爆炸根本原因是文档与代码是两份独立维护的事实。手工同步必然脱节。5.2 v3.3.0 的解法从注解直接生成 OpenAPI 3.1kylix doc --openapi --title My API --api-version 1.0.0 api.klx输出docs/api/openapi.yamlopenapi: 3.1.0 info: title: My API version: 1.0.0 paths: /api/v1/users: post: operationId: TUserController_CreateUser requestBody: required: true content: application/json: schema: $ref: #/components/schemas/TCreateUser responses: 200: description: OK components: schemas: TCreateUser: type: object required: [Email, Password] properties: Email: type: string format: email Password: type: string minLength: 8 securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT注意几个关键映射Kylix 注解OpenAPI 字段[Controller(/api/v1)][Post(/users)]paths→/api/v1/users→post[Body(TCreateUser)]requestBody.content.application/json.schema.$ref[Entity][Required]/[Email]/[Min]等components.schemas.TCreateUser[Authenticated]/[Role]components.securitySchemes.BearerAuth5.3 这意味着什么第一单一事实来源代码就是文档。改代码 → 重新跑kylix doc --openapi→ 文档自动更新。前端、QA、外部合作方拿到的 OpenAPI 永远和真实运行的服务对齐。第二零运行时开销FastAPI 的 OpenAPI 是运行时生成的——服务启动时反射扫描所有路由构造 schema。Kylix 是编译期生成——不需要服务在跑纯静态分析.klx源文件就能产出文档。第三与 Kylix 路径参数语法的语义桥接CHANGELOG 里有一句话自动转换 Kylix 路径参数:id→{id}并生成 Bearer 认证方案。Kylix 用 Pascal 风格的:idOpenAPI 用{id}——kylix doc --openapi在生成时自动转换。这是一个小细节但说明设计者真正理解 OpenAPI 规范、并尊重它的约定。5.4 接下来可以做什么只要openapi.yaml生成出来了整个 OpenAPI 生态都可以为你所用•swagger-ui→ 直接渲染交互式文档•openapi-generator→ 一键生成 TypeScript / Python / Java 客户端 SDK•prism/dredd→ 用 OpenAPI 做 Contract Test•postman→ 一键导入接口集合Kylix 第一次实现了写 Kylix 后端 生成 TypeScript 前端 SDK的端到端闭环。5.5 已知限制嵌套对象 schemaCHANGELOG 坦诚地写OpenAPI 生成器不支持嵌套对象 schema仅顶层属性这是一个有意识的 MVP 边界——大多数 REST API 的请求体不会有超过两层嵌套user 里嵌 address 这种先把 80% 的场景做完美剩下的嵌套场景作为 v3.4 的迭代。这种克制的产品节奏和之前 LLVM M2 留出的延期清单是一脉相承的。六、包管理器与编译器的最后一公里打通这是一项看上去不起眼但开发体验上杀手级的改进。6.1 v3.3.0 之前的尴尬kylix add github.com/user/http # ✅ 文件被下载到 packages/http/http.klx # ❌ 但 kylix build main.klx 找不到这个文件 # 你必须手动 kylix build main.klx packages/http/http.klx # 或者配置一些复杂的 import 路径包管理器能加包但编译器不知道。这种两个工具各干各的的状态会让用户极度困惑——我都kylix add了为什么uses http还是报错6.2 v3.3.0 的修复CompileProject现在自动发现packages/*/目录下的所有.klx文件kylix add github.com/user/http # 1. 添加依赖 # kylix.toml 自动更新, packages/http/http.klx 自动创建 kylix build main.klx # 2. 编译 # 编译器自动扫描 packages/*/, http.klx 自动加入编译列表 # main.klx 里 uses http; 直接可用6.3 去重逻辑避免重复编译CHANGELOG 里提到一个 bug 修复包管理器文件重复编译CompileProject现在对PackageSearchDirs和显式传入的文件去重这是真实的工程细节——如果用户同时kylix build main.klx packages/http/http.klx手动传入和packages/*自动扫描http.klx就会被编译两次导致符号重复定义。新版本用map[string]bool去重无论用户怎么传都只编译一次。6.4 测试覆盖packages_test.go上线新增的packages_test.go验证• 包管理器能正确发现packages/*子目录• 显式传入与自动扫描结合时的去重逻辑• 多层嵌套包的处理CHANGELOG 这一段读起来波澜不惊——但要知道过去这块代码的测试覆盖率是0详见 CLAUDE.md 列出的已知技术债 3.1。现在pkg/pkgmgr终于有了自己的测试这是 Kylix 工程化进程的又一块拼图归位。七、类型检查器 MVP862 行的质量护栏虽然 CHANGELOG 标注为Type checker already complete——意思是这部分在内部其实更早就在做了——但它第一次在 v3.3.0 被作为发布亮点公开。7.1pkg/compiler/typecheck.go覆盖的检查✅ 未声明变量/函数引用 ✅ 函数调用参数数量不匹配 ✅ 赋值类型兼容性 ✅ 泛型约束验证 ✅ 接口实现验证含继承链 ✅ 类型别名循环检测862 行代码 7 个测试场景— 这是把 Kylix 的编译期质量护栏从原本的语法层 代码生成层扩展到了完整的语义层。7.2 一个具体例子泛型约束验证type IComparable interface function CompareTo(other: T): Integer; end; type TBox class // ← T 必须实现 IComparable Value: T; end; var box: TBox; // ❌ Integer 不实现 IComparable // 编译期立刻报错无需等到代码生成失败这种检查的关键价值不是找到 bug——而是把错误前移。以前类似的错误可能只能在生成 Go 代码、Go 编译器报错、用户翻译错误信息回 Kylix 上下文才能定位现在 Kylix 直接在源码层面报错错误信息精准、行号精准、上下文精准。7.3 与Kylix 层错误报告v3.1.x的呼应第 24 篇文章里我曾详细介绍过 Kylix v3.1.x 的Kylix 层错误报告——把 Go 编译器的报错翻译回 Kylix 上下文。类型检查器是这套设计的延伸能在 Kylix 层就抓住的错误不要让它流到 Go 层再被抓。两者结合形成了双层防护1. 第一道类型检查器前置主动2. 第二道Go 错误翻译器后置兜底这种防御纵深的工程实践是任何产品级编译器都必须有的。八、性能改进增量编译被实测验证CHANGELOG 给出了具体数字场景编译时间加速比冷编译 10 个单元文件4.2ms1.0x热编译全部缓存命中1.1ms3.7x部分缓存修改 1 个文件1.2ms3.6x关键观察v1.5.0 时代我们说增量编译有 55× 加速——那是基于一个更大的项目基准。这次的数字看起来温和是因为基准换成了 10 个单元的小型项目。但更重要的是这是第一次有performance_test.go这种正式的基准测试。之前55× 加速是手测的现在变成了 CI 可以跑的基准。性能从此可被回归保护——任何一次代码改动如果让编译性能退化CI 立刻报警。这是真正的工程化。九、版本演进的承上启下让我们把视野拉远看 v3.2.0 和 v3.3.0 的关系。9.1 v3.2.0注解栈的骨架v3.2.0 完成了什么[Controller] ← 路由 [Service] ← DI [Required] ← 校验 [Authenticated]← 安全接口契约 [Entity] ← ORM这是一套完整的注解骨架——所有注解、所有诊断码、所有运行时支撑全部就位。但这套骨架还缺少肌肉•[Authenticated]有契约但没有默认实现用户必须自己写 AuthValidator• POST/PUT 路由能写但没有声明式 Body 绑定• 注解信息全在编译器里但没法导出给外部世界前端、文档、API gateway9.2 v3.3.0把肌肉长到骨架上v3.3.0 一次性补齐了三块关键肌肉v3.2.0 骨架 → v3.3.0 添加的肌肉 ───────────────────────────────────────────── [Authenticated] 契约 → JWT HS256 默认实现 BootRegisterJwtAuth [Post] / [Put] → [Body(T)] 声明式 Body 绑定 注解信息内部 → OpenAPI 3.1 自动导出v3.2.0 v3.3.0 一个完整的 KylixBoot 框架。从这两个版本开始KylixBoot 可以宣称自己是一个现代化的、声明式的、编译期安全的 Pascal 后端 Web 框架。9.3 一张表对比v3.2.0 vs v3.3.0维度v3.2.0v3.3.0注解栈完整骨架骨架 Body 绑定肌肉认证[Authenticated]契约 JWT 默认实现文档无OpenAPI 3.1 自动生成类型检查编译时报错基础 862 行类型检查器 MVP包管理工具能加包工具与编译器打通LLVM 后端M2 完整不变无新增stdlib13 模块14 模块jwt教程42/4245/453 新示例错误码KLX207–213KLX214KLX301 冲突修复包测试pkg/pkgmgr零覆盖packages_test.go性能测试手测 55×performance_test.go自动基准十、深度分析v3.3.0 体现的产品成熟度把 v3.3.0 单独拎出来读一遍 CHANGELOG你会发现它和之前所有 Kylix 版本都不太一样10.1 这是第一个被产品需求驱动的版本之前的版本主题大多是编译器能力——LLVM 后端、增量编译、泛型、接口验证、注解栈。开发者视角的我希望编译器能做什么。v3.3.0 的主题完全不同——它讨论的是 Body 绑定、JWT、OpenAPI、包管理器集成——用户视角的我希望写 Web 服务时能少做什么。这是 Kylix 项目第一次明显地从我有什么转向用户要什么。这种转向通常发生在编译器项目走向成熟的某个临界点——而 v3.3.0 看起来就是那个临界点。10.2 错误码冲突的修复说明了什么ErrBodyBinding从 KLX301 迁移到 KLX214 的修复技术上很微小但它的存在本身说明 Kylix 团队在做一件事审视并维护错误码体系的一致性。成熟的工业级编译器GCC、Clang、Rustc都有错误码作为产品契约的意识——错误码一旦发布就是用户文档的一部分错误码冲突是必须修复的契约违反。v3.3.0 主动做这件事说明 Kylix 已经把自己当成一个长期维护的产品而不是一个一直在改的实验。10.3 已知限制的坦诚CHANGELOG 末尾列出了两条已知限制•CompileFile单文件模式不自动解析uses依赖需手动传入所有文件或使用项目模式• OpenAPI 生成器不支持嵌套对象 schema仅顶层属性这种坦诚是开源项目的最高级礼貌。它告诉用户• 我们知道什么能用、什么不能用• 你不会在生产环境踩到我们没说过的坑• 如果你正好需要这个被列出的限制请等 v3.4 或者自己 PR这是 Linus Torvalds 在 Linux 邮件列表里反复强调的态度Never silently break userspace.永远不要悄悄地破坏用户空间10.4 向后兼容的承诺CHANGELOG 升级指南第一句话从 v3.2.0 升级到 v3.3.0 无需修改现有代码。新功能全部向后兼容。这是一个强承诺。在一个仍处于 v3.x 的快速迭代项目里能做到这一点说明• API 设计的内聚性强新功能不需要改既有 API• 错误码扩展而不是替换KLX214 是新加的KLX213 之前的全保留• 注解语法是叠加式的[Body]加在[Post]旁边不替换[Post]向后兼容是工业级编程语言的硬指标。Kylix 在 v3.3.0 兑现了这个指标。十一、对竞争格局的新定位如果用一张表对比当下主流后端框架的注解能力v3.3.0 的 KylixBoot 已经处在什么位置能力Spring Boot (Java)FastAPI (Python)NestJS (TS)KylixBoot (Kylix)路由注解✅RestController✅app.get✅Controller✅[Controller]/[Get]DI 自动装配✅Autowired✅Depends()✅Injectable✅[Inject]字段校验✅Valid JSR-380✅ Pydantic✅class-validator✅[Required]/[Email]Body 绑定✅RequestBody✅ Pydantic 模型✅Body()✅v3.3.0[Body(T)]JWT 内置⚠️ 需 Spring Security⚠️ 需 PyJWT⚠️ 需 nestjs/jwt✅v3.3.0uses jwtOpenAPI 生成✅ springdoc✅ 内置运行时✅ nestjs/swagger✅v3.3.0编译期生成ORM 注解✅ JPAEntity⚠️ SQLAlchemy 单独✅ TypeORM✅[Entity]/[Repository]编译期 vs 运行时运行时反射运行时运行时编译期生成代码KylixBoot 在 v3.3.0 之后第一次在功能矩阵上对齐了主流 Web 框架。它的差异化优势1.编译期生成 vs 运行时反射— 零反射开销启动即满速2.强类型 Pascal— 比 Python / JS 的弱类型更早抓 bug3.多后端编译— 同一份 Kylix 代码能编译到 Go binary、WASI、LLVM native4.完整的工具链一体化— kylix 一条 CLI 命令完成 build / test / fmt / doc / publish十二、统计快照v3.3.0 GA 时刻指标v3.2.0昨天v3.3.0今天变化教程示例42/4245/453Body / JWT / OpenAPIstdlib 模块1314jwt1KLX 诊断码上限KLX213KLX2141修复冲突包测试0packages_test.go上线新增类型检查器内部公开 862 行 7 测试MVP 完整性能基准测试手测performance_test.go自动化包管理器集成度部分完全打通✅OpenAPI 自动生成❌✅ 3.1 标准新能力JWT 内置❌✅ HS256新能力Body 绑定手写✅ 注解新能力Go 测试通过率16 包全通16 包全通稳向后兼容性—✅ 100%兑现十三、下一步v3.4 / v4.0 的两条线索13.1 v3.4 / v3.5 的可能方向CHANGELOG 没明确说但从这次的已知限制可以推测•嵌套对象 schema 的 OpenAPI 生成——补齐复杂请求体场景•CompileFile单文件模式的 uses 依赖解析——让单文件场景也自动化•JWT 算法扩展RS256 / ES256HS256 之外的非对称算法•KylixBoot 的更多默认中间件限流、缓存、CSRF、压缩•OpenAPI 反向从 yaml 生成 Kylix stub— Schema-First 开发流13.2 v4.0 的完全脱离 Go路径第 29 篇我详细分析过 v4.0 的核心目标——LLVM Milestone 3 KylixRT。v3.3.0 选择纯 Go stdlib 实现 JWT、不引入外部依赖是为这条路径继续清地基。每多一个外部 Go 依赖v4.0 的 LLVM 后端就多一份移植负担。按照当前节奏v4.0 的发布时间表可能比 ROADMAP 预期的 2027 年提前到 2026 年第四季度。这是非常激进的判断但看着这几周的密度并不夸张。十四、第三十篇收尾从个人 side project到准生产级语言这是 Kylix 项目追踪系列的第三十篇。我想用三句话总结过去 30 篇文章串起来的整条 Kylix 发展故事第一句从无到有。Kylix 不是一夜建成的。前 14 篇文章记录了它如何从词法分析器开始一行行写到自举成功。每一篇都意味着一个新增的语言特性、一个解决的编译器 bug、一段被攻克的实现难关。第二句从有到好。v2.x 到 v3.2.0Kylix 的工作重心从能跑转向好用——LSP、REPL、增量编译、KylixBoot 框架、注解栈、LLVM 后端、stdlib 大幅扩张。这是从原型到产品的转化。第三句从好到全。v3.3.0 是 Kylix 第一次有底气说自己全——•语言全类、接口、泛型、异常、模式匹配、属性、字符串插值、async/await现代语言特性齐备•编译全Go 后端 LLVM 后端 WASI 后端三个 target 都能生产可执行文件•生态全stdlib 14 模块 KylixBoot Web 框架 ORM 注解 JWT 认证 OpenAPI 生成 包管理器 包注册中心•工具全build / test / bench / fmt / doc / repl / lsp / publish / new一个kylix命令通吃•质量全862 行类型检查器 Kylix 层错误报告 增量编译 性能基准测试 16 包测试覆盖Kylix 已经不是一个试图实现现代 Pascal的实验项目了。它是一个准生产级编程语言。14.1 写给 Kylix 团队的话第三十篇是个里程碑但绝不是终点。从 v3.3.0 出发前方还有• v3.4 的产品化打磨• v3.5 的生态扩展• v4.0 的完全脱离 Go——KylixRT 自研运行时• 中长期的社区建设、IDE 插件、企业模板、真实项目落地每一步都比上一步更难。但 Kylix 已经证明了一件事这个团队的开发节奏、工程克制、质量意识是一流的。14.2 写给读者的话如果你是第一次读这个系列——欢迎来到第三十篇。前 29 篇构成了一个完整的现代编程语言从零到生产级的工程实录每一篇都尝试不止记录做了什么更试图回答为什么这样做和这样做意味着什么。如果你是从第一篇追到第三十篇的老读者——感谢你的陪伴。Kylix 这个项目证明了一个由人精心打磨、节奏稳健、设计克制的编程语言项目可以在不到半年时间里从原型走到准生产级。这本身就是一个值得书写的故事。14.3 三句话总结 v3.3.01.KylixBoot 完整了Body 绑定 JWT OpenAPI 三大缺口一次性补齐与 Spring Boot / FastAPI / NestJS 同台竞争的最小可用面已经成立。2.工程基建完整了类型检查器 MVP 包管理器编译器集成 性能基准测试 错误码冲突修复每一项都把 Kylix 往工业级推了一步。3.承上启下完整了v3.2.0 的注解骨架在 v3.3.0 长出了肌肉v3.3.0 的纯 Go stdlib 实现为 v4.0 的脱离 Go铺平地基。Kylix v3.3.0一个能写真正的生产级 Web 服务的 Pascal。从 v1.0 到 v3.3.0从词法分析器到 OpenAPI 自动生成30 篇文章13 个月无数行代码。下一个 30 篇见。本文是 Kylix 项目追踪系列的第三十篇基于 2026 年 6 月 29 日 v3.3.0 正式发布时的项目状态编写。附录v3.3.0 速查编译期 Body 绑定[Post(/users)] [Body(TCreateUser)] function CreateUser(req: TRequest): TResponse;JWT 一行接入uses boot, jwt; BootRegisterJwtAuth(my-secret);OpenAPI 一行生成kylix doc --openapi --title My API --api-version 1.0.0 api.klx包管理器自动集成kylix add http kylix build main.klx # packages/http/http.klx 自动被发现完整 CHANGELOGhttps://github.com/astra-zhao/kylix/blob/main/CHANGELOG.mdRelease Noteshttps://github.com/astra-zhao/kylix/blob/main/RELEASE\_v3.3.0.md官方网站kylix.top[2]引用链接[1]astra-zhao/kylix:https://github.com/astra-zhao/kylix[2]kylix.top:https://kylix.top
