Neton Framework 1.0.0 正式发布，现已上线 Maven Central。

这是 Neton 的第一个稳定版本。从应用装配、依赖注入、HTTP API，到数据库、认证授权、缓存、任务调度、对象存储和 WebSocket，Neton 为 Kotlin 开发者提供了一套围绕原生服务端应用构建的开发体系。

Neton 的定位不是底层网络库，而是与 Spring Boot、Laravel 处于相近应用开发层次的服务端框架：帮助开发者组织业务、整合基础设施、交付可维护的后端服务。不同之处在于，Neton 选择 Kotlin/Native 作为运行基础，以编译期代码生成、明确的模块契约和可执行验收作为工程核心。

用 Kotlin 编写业务，编译为原生可执行程序；让开发者和 AI 助手都能够按照同一套规范构建服务。

一、原生服务端开发，内存占用堪比 Go 语言

Neton 应用通过 Kotlin/Native 编译为原生可执行程序，运行时不需要部署 JVM。

开发者仍然可以使用 Kotlin 的类型系统、协程、扩展函数和 DSL 来组织业务，但应用装配不依赖运行期类路径扫描，也不通过反射发现控制器和数据模型。

Neton 使用 KSP 在编译期生成路由处理、服务注册、实体映射和请求校验等代码，将一部分原本只能在运行时发现的问题提前到编译阶段。

对于业务开发者而言，这意味着：

• 使用 Kotlin 类型和构造函数表达依赖关系。

• 使用注解或 DSL 定义接口。

• 使用生成的代码连接控制器、业务逻辑和基础设施。

• 在编译、测试和发布验收中检查契约是否成立。
  原生运行并不意味着所有依赖都由 Kotlin 实现。Neton 在数据库驱动、加密等领域复用专门的底层能力，同时通过框架接口保持业务代码的边界。

二、从应用入口到优雅停机，统一管理资源生命周期

一个服务端框架不应只负责“把接口启动起来”。

数据库连接、HTTP 客户端、Redis 连接、后台任务和 WebSocket 会话，都需要明确的创建、运行和退出过程。缺少统一管理，应用往往能够正常启动，却无法可靠停止。

Neton 提供统一的 Neton.run 入口和组件安装 DSL，配合类型化服务绑定、模块依赖声明和初始化机制完成应用装配。

服务启动后，注册上下文进入冻结状态，避免请求处理期间动态修改装配关系。启动失败、协程取消和正常退出也纳入生命周期契约，让资源释放成为框架行为的一部分。

在 1.0 的发布验收中，参考应用不仅需要构建成功，还必须完成迁移、两轮健康运行和停机检查，并确认端口关闭、数据库连接归零。

三、完整的 HTTP API 开发能力

Neton 同时提供 Kotlin 路由 DSL 和注解式控制器，开发者可以按项目需要选择，或在同一应用中组合使用。

HTTP 应用层能力包括：

• 路由分组与挂载配置。

• 请求参数和请求体绑定。

• JSON 序列化与类型转换。

• 中间件、拦截器及安全扩展点。

• 统一响应封装、异常映射和结构化错误。

• CORS 与路由级限流。

• 静态文件、条件请求、单范围请求和预压缩资源。

• 流式响应与 Server-Sent Events。
  请求校验同样进入编译期体系。开发者在 DTO 上声明字符串、长度、数值范围、邮箱或嵌套校验规则，由 KSP 生成校验器，并接入生成的请求处理流程。
  不支持的注解位置或用法会触发编译错误，而不是看似声明了校验、运行时却悄悄跳过。

四、数据库：类型化操作，也保留 SQL 的表达能力

• Neton 数据访问强调职责分离： 实体负责表达数据，Table 和 Query API 负责持久化操作，业务逻辑负责组合业务流程。
  1.0 提供：

• 类型化 CRUD、过滤、排序和分页。

• 实体元数据与映射代码生成。

• 类型化投影、连接查询与聚合查询。

• 显式数据库会话和事务。

• 参数化原生 SQL。

• 原子递增、递减和带条件更新。

• 软删除、自动字段及查询拦截扩展点。
  类型化 DSL 不是对 SQL 能力的封闭。对于 DSL 尚不能表达的查询，开发者可以通过 DbContext 执行参数化 SQL，仍然遵守统一的会话和事务边界。
  数据库迁移也有独立的执行流程，支持版本化脚本、迁移历史，以及 up、status、verify 等命令。生产结构变更应作为部署动作明确执行，而不是隐藏在服务启动过程中。
  本次正式版默认数据库制品采用 PostgreSQL，并升级至 sqlx4k 1.17.0。

五、认证、授权与加密，提供通用机制而不绑定业务身份

Neton Framework 提供可组合的认证器和 Guard、角色与权限检查、匿名访问声明，以及 JWT、RSA/JWKS 和令牌内省等集成能力。

身份信息绑定在当前请求上，而不是保存在进程级全局状态中。控制器可以通过当前用户注入获取身份，业务代码也可以使用请求绑定的安全上下文。

框架同时提供密码哈希、安全随机数、摘要、HMAC、认证加密、SecretBox 和 TOTP 等基础能力。

HTTP/TLS、Security 和 Storage 统一使用项目的 OpenSSL 4 封装，避免在同一个原生程序中引入冲突的 OpenSSL 主版本。加密后端迁移也覆盖了已存储密码哈希和 SecretBox 数据格式的兼容性回归。

• 这里的边界同样重要： 框架提供 TOTP 等安全原语，但 MFA 绑定界面、恢复流程、验证码提供方和管理员策略属于上层应用，而不是强行塞入通用安全模块。

六、Redis、缓存、任务和事件，不必每个项目重新搭建

除了 HTTP 和数据库，Neton 还整合了常见后端基础设施。

Redis 与缓存

提供托管连接、类型化值读写、过期控制和分布式锁，以及结合本地 L1 与 Redis L2 的命名缓存。缓存支持 TTL、本地容量边界和明确的编解码方式。

支持的控制器缓存注解由 KSP 接入生成代码，不依赖对任意方法进行运行期 AOP。缓存数据损坏时按未命中处理，不将原始内容写入日志。

后台任务

支持 Cron、固定频率、手动触发和运行状态查看，可配置所有节点执行或通过 Redis 协调的单节点执行。停机时停止接收新任务，并在截止时间内等待已接收任务完成。

领域事件

提供类型化事件总线，区分同步、尽力而为和可重试投递。需要持久化的模式必须明确接入存储与编解码设施，不会因为缺少配置而静默退化。

这些机制帮助业务模块协作，但不会把事件总线包装成已经具备所有能力的消息中间件，也不承诺恰好一次处理或全局顺序。

七、文件与对象存储，统一接口、明确边界

Neton Storage 提供统一的存储操作接口，支持本地文件系统和 S3 兼容服务。

业务可以通过命名存储源使用读写、删除、存在性检查、元信息、列表、复制和移动等操作；S3 实现还提供预签名读写 URL。

S3 请求复用框架 HTTP 客户端和加密能力，而不是再引入另一套独立网络实现。

当前存储接口面向小文件字节数组操作，不将其描述为已经完整支持超大文件分片、断点续传或视频转码。媒体归属、审核和业务访问策略由上层应用负责。

八、WebSocket 是正式能力，而不是附带演示

实时通信是 Neton 1.0 的重要组成部分。

可选的 neton-websocket 模块提供稳定的业务 API，统一命名空间为 neton.websocket，支持：

• DSL 路由、注解控制器和可注入的处理器。

• 内置默认引擎。

• 升级握手前的认证、限流、参数绑定和 Origin 检查。

• 会话管理、连接标识、文本与二进制消息。

• 心跳、有界队列、背压与资源准入限制。

• 入站消息交付、拒绝和校验后丢弃策略。

• 可观察的关闭结果与停机清理。
  普通应用使用的 WebSocket API 与引擎扩展 SPI 分开管理：业务 API 纳入稳定版本，引擎 SPI 仍需显式选择实验性接口。
  WebSocket 压缩、HTTP/2 和 HTTP/3 扩展 CONNECT、高层 Hub 与类型化消息体系不属于本次发布范围。

九、自有网络基础设施，为应用层提供统一底座

Neton 默认 HTTP 服务端和客户端建立在自有 Kotlin/Native HTTP、I/O 与 TLS 库之上。

这套底座提供 HTTP/1.1、HTTP/2、TLS/ALPN、连接池、流式响应、取消、超时和 HTTP 代理等能力，并提供支持隐式 TLS、STARTTLS 和认证的 SMTP 传输。

这些是支撑框架的基础设施，而不是要求业务开发者直接操作网络协议。业务应面向框架接口编程，由底层组件承担传输和资源管理。

Ktor、Hyper4k 和 Geario4k 适配器已经独立为可选的兼容或对比项目，不再作为默认传输或核心发布门禁。QUIC、HTTP/3 则属于更广泛的协议生态，不能直接等同于本次 Framework 1.0 已认证的服务能力。

十、AI 原生：让 AI 按框架规范开发，而不只是生成代码

Neton 所说的“AI 原生”，首先是开发方式，而不是给每个应用自动接入大模型。

AI 可以快速生成代码，但一个真实服务还必须遵守模块边界、事务语义、身份隔离、生命周期和迁移规范。代码能够编译，并不代表服务已经正确交付。

因此，Neton 将规范和开发 Skill 作为生态的一部分，集中维护在 neton-docs 中，指导开发者与 AI 助手：

• 根据项目版本查找真实可用的 API。

• 使用标准应用入口和生成机制。

• 遵守模块、服务与基础设施边界。

• 正确处理事务、取消和资源释放。

• 为功能补齐回归与验收测试。

• 区分稳定契约、实验性 API 和尚未实现的规划。
  Neton + Skill 的目标，是让 AI 辅助开发从“能生成代码”，走向“按框架标准交付可验证的服务”。
  Skill 不会替代编译和测试，也不保证任意业务自动正确。项目仍需提供自身需求和验收条件。
  运行期 AI 集成则放在独立的 neton-ai 仓库中，拥有独立版本与发布节奏，不要求模型生态每次变化都推动核心框架重新发布。

十一、1.0 不只是版本号：公开制品与运行验收已经完成

Neton 1.0.0 的发布源码通过了全部 19 项发布门禁，覆盖公开 API/ABI、源码消费兼容性、KSP 增量生成、原生测试、真实 PostgreSQL/Redis 契约和候选制品验收。

完整原生运行门禁覆盖：

• macOS ARM64

• Linux x64

• Windows x64
  公开模板 neton-app 已在这三个平台直接消费 Maven Central 上的正式制品，完成 release 构建与两轮运行验收。
  此外，独立的 macOS ARM64 数据库消费项目在不使用 Maven Local、候选仓库和源码替换的条件下，完成迁移检查、两次 release 构建和两轮健康启停，并在清理测试环境前确认数据库连接归零。
  正式发布包含 79 个 Maven 坐标、345 个制品正文文件。公开文件的大小、SHA-256 和签名均已与生产清单核对。

• 平台支持仍按实际证据说明： Linux ARM64 已有独立的 KSP 实际执行门禁，但不等于完整运行认证；macOS x64 的库编译也不等于完整运行验收，数据库模块不提供该目标制品。

十二、开始使用 Neton 1.0

• 在配置 Maven Central 的 Kotlin Multiplatform 项目中添加：

commonMain.dependencies {
    implementation("com.netonstream:neton:1.0.0")
    // 按需添加，由 Framework BOM 对齐版本
    implementation("com.netonstream:neton-security")
    implementation("com.netonstream:neton-database")
    implementation("com.netonstream:neton-websocket")
}

入口依赖包含 Core、Logging、HTTP 和 Routing。数据库、安全、WebSocket 等能力按需添加；使用生成 API 时，需要同步对齐 neton-ksp。

首次使用建议从公开的 neton-app 模板开始，复用经过验收的构建配置，并安装与版本匹配的开发 Skill。

Neton 1.0 的目标，是为 Kotlin 原生服务端开发建立一个清晰、可组合、可验证的工程基础：让基础设施遵守统一契约，让业务保持自己的表达空间，让人类开发者与 AI 助手能够在同一套标准下协作。

1.0 是稳定契约的起点，也是持续完善生态的开始。

项目链接：

• 官方文档：https://neton.tech/

• 框架源码：https://github.com/netonframework/neton

• 正式发布：https://github.com/netonframework/neton/releases/tag/v1.0.0

• 应用模板：https://github.com/netonframework/neton-app

• 开发 Skills：https://github.com/netonframework/netonframework.github.io/tree/main/skills

• Maven Central：https://central.sonatype.com/artifact/com.netonstream/neton/1.0.0