kratos 官方上线的 v3 中文文档，已经把这个框架的定位说得非常清楚：kratos v3 是主打轻量的 go 云原生服务框架，提供应用生命周期管理、自动生成的 http/grpc 传输层、中间件、配置、结构化错误处理、元数据、编解码、日志和服务发现接口。文档同时特意说明，持久化、注册中心、遥测、远程配置这些能力，需要应用通过独立模块自行选择实现，直接把框架核心能力和业务侧基础设施的边界划得清清楚楚。
来源：Kratos 官方文档
官方仓库的 README 也同步更新了 v3 的统一表述，页面明确标注 Kratos 是面向云原生微服务的轻量 Go 框架，主打传输层、中间件、注册中心、配置、日志、编解码、代码生成这些体量小、职责清晰的 API。安装要求里列出需要 Go 1.25 及以上版本，CLI 安装命令也改成了 `github.com/go-kratos/kratos/cmd/kratos/v3@latest`，这点对新开的项目特别关键，直接决定了后续使用的工具链和模块路径。
来源：Kratos GitHub README
这次 v3 版本最核心的信息架构调整，是把「Core 核心包和 contrib 贡献包分开说明」：JWT、OpenTelemetry 链路追踪/指标采集、各类注册中心、配置中心还有部分编解码能力，不再是框架默认给项目配好的隐式自带能力，而是要求开发者按需引入独立模块。这么做虽然会增加版本迁移时的检查项，但能大幅缩减核心包的依赖体积，数据库、队列、缓存、遥测导出器、部署策略这些组件，完全交给应用侧自行选择。
从实际使用的角度来说，Kratos v3 的文档不再只面向「先跑通 Demo」的入门流程，而是把已有 v2 服务迁移、新项目初始化、组件说明、布局示例全部放在同一级入口下。团队评估要不要升级的时候，可以先看官方文档首页确认核心模块的行为变化，再进迁移指南页逐一处理 Go 模块、日志、JSON、JWT、OpenTelemetry 这些改动点，顺着这个路径梳理出来的迁移计划，比零散翻发布说明要靠谱得多。
README 列出的特性还显示，Kratos 依然沿用 Protobuf 优先的开发模式，通过代码生成直接产出 HTTP/gRPC 的业务代码，省去大量重复的胶水层开发工作。对于需要做微服务分层、接口自动生成、服务注册发现的项目来说，v3 文档最大的价值就是先把框架负责的边界说透，剩下的数据库、缓存、队列、部署策略全部交给团队自己选型，这种表述方式减少了很多不必要的误解，也降低了用户误把框架当成一整套业务平台来使用的风险。
信源说明：本文内容全部整理自 Kratos v3 官方中文文档和 go-kratos/kratos 官方 README，没有引用第三方评测或者社区非官方猜测，实际项目落地时的适配范围，请以官方文档、GitHub Release 和项目自身的依赖树校验结果为准。
