无痛编写 Kotlin AWS 代码：告别 Java 历史包袱

在 Kotlin 中使用 AWS 的开发者可能还记得 Java SDK v2。虽然在 Kotlin 项目中使用它是可行的，但你需要不断地将 CompletableFuture 包装在协程中，忍受冗长的 Java builder 语法，还要在构建中引入额外的依赖。AWS 团队通过官方项目 aws-sdk-kotlin 解决了这个问题——这是一个从零开始专为 Kotlin 编写的客户端。

原生 Kotlin SDK 带来的变化

该库的主要优势是原生协程支持和 Kotlin Flow。无需回调地狱或异步包装器。对 S3、DynamoDB 或 Lambda 的调用写法与 Kotlin 中任何其他异步代码完全一致。

第二个重要点是多平台架构基础。该库面向 Kotlin Multiplatform，可开箱即用于多个目标平台：

• JVM，用于 Ktor 或 Spring 上的经典后端
• Android，用于移动应用
• GraalVM Native Image，用于编译二进制文件的快速启动

通过 Smithy 进行代码生成和定向构建

AWS 有数百种服务。如果将每种服务的客户端编译打包成一个库，最终产物会变得非常大。SDK 作者通过基于声明式 Smithy 语言的代码生成解决了这个问题。

仓库中不包含每种 AWS 服务的预生成代码。代码在项目构建期间生成。如果你从源码构建 SDK，可以只指定应用程序中实际需要的服务。

配置过滤在 local.properties 文件中进行：

如果需要从构建中移除某些服务，使用减号：

代码生成通过 Gradle 触发：

之后，使用标准任务构建生成的模块：

这种方法在本地开发和测试单个 SDK 模块时节省了时间。

通过 Dokka 构建文档

对于代码文档，开发者使用 Dokka——这是 JetBrains 的标准工具，支持 KDoc 格式。

要在本地生成 API 参考文档，仓库提供了命令：

生成的 HTML 文档进入 build/dokka/htmlMultiModule 目录。要在浏览器中打开它，需要任何简单的 HTTP 服务器，例如 IntelliJ IDEA 内置的服务器或通过 Python 启动的服务器：

是否值得迁移到 Kotlin SDK

该仓库在 GitHub 上约有 500 颗星。这个数字相对较小，因为该项目长期处于活跃开发状态，许多团队习惯使用 Java SDK v2。尽管如此，该库已经可用于生产环境，并得到 Amazon 的官方支持。

该库在以下四种场景中特别有用：

• 你正在构建一个 Android 应用，需要直接访问 AWS 服务，而不想引入繁重的 Java 依赖。
• 你正在为 AWS Lambda 编写 Kotlin 无服务器函数，并使用 GraalVM Native Image 编译，冷启动速度至关重要。
• 你的后端完全基于协程和 Ktor 构建，你希望保持一致的异步代码风格。
• 你正在制作一个多平台模块，将移动端和服务器的逻辑结合在一起。

如果你已经有一个基于 Spring Boot 的大型遗留项目，使用旧的 Java SDK，则无需急于重写。但对于 Kotlin 中的新服务和应用，这个 SDK 看起来是合理的选择。