Ktor中call.receive<T>()为何会自动将JSON数组中的非字符串项反序列化为字符串类型？

你遇到的这个差异，本质上是Ktor默认的序列化配置和kotlinx.serialization的默认Json实例配置不一样导致的，我来一步步给你拆解：

1. Ktor的默认宽松转换特性 #

当你在Ktor中调用install(ContentNegotiation) { json() }时，这个json()方法默认使用了带有宽松输入转换的配置。具体来说，它背后创建的Json实例核心配置是：

Json {
    coerceInputValues = true // 核心：开启自动类型转换
    // 还包含 ignoreUnknownKeys = true 等其他默认兼容配置
}

这个coerceInputValues = true的作用是：当序列化器遇到JSON中类型与目标Kotlin类型不匹配的字段时，会尝试自动做隐式转换。比如：

• 数字会被转成对应的字符串（就像你例子里的1→"1"）
• 布尔值true/false会被转成"true"/"false"
• 空值可能会被填充为目标类型的默认值（比如Int的0，String的空串）

这就是为什么你的测试请求里的数字1能被“无缝”转成字符串，顺利反序列化到List<String>里。

2. 直接用kotlinx.serialization.Json的默认严格模式 #

而当你直接调用Json.decodeFromString<TestingDTO>(...)时，你用的是kotlinx.serialization提供的默认严格模式的Json实例，它的核心配置是coerceInputValues = false。在这种模式下，序列化器会严格校验JSON类型与目标类型是否完全匹配，一旦发现不匹配的类型（比如你例子中数组里的数字1对应目标的String类型），就会直接抛出序列化异常，这也是你看到的“预期失败”的情况。

3. 让Ktor也启用严格模式的方法 #

如果你想让Ktor的call.receive<T>()和直接用Json.decodeFromString行为一致，只需要在配置ContentNegotiation时显式关闭宽松转换即可：

install(ContentNegotiation) {
    json(Json {
        coerceInputValues = false // 关闭自动类型转换
        // 可按需保留 ignoreUnknownKeys = true 等其他配置
    })
}

修改后再发送同样的请求，call.receive<TestingDTO>()就会抛出类型不匹配的异常，和直接用kotlinx的Json类表现完全一致。

4. 这种自动转换的方式是否值得用？ #

这要结合你的API场景来判断：

• 如果你的API需要严格校验输入类型，比如必须确保所有输入都是符合预期的String类型，防止非法数据流入，那应该关闭coerceInputValues使用严格模式。这样能提前发现客户端的输入错误，避免隐式转换带来的潜在问题。
• 如果你的API需要兼容一些不严格的客户端输入（比如某些前端框架可能会把数字类型的ID自动转成数字发送，而你的接口期望String类型），那默认的宽松模式可以减少对接成本，但要注意：这种转换只支持基本类型之间的合理转换，复杂类型（比如JSON对象转String）还是会失败，而且隐式转换可能会让你错过一些潜在的输入错误。

备注：内容来源于stack exchange，提问作者Lucas Sousa