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 是稳定契约的起点，也是持续完善生态的开始。
项目链接：