启用WasmJS构建目标后KMP共享模块String.format无法使用

问题原因 #

String.format并非Kotlin多平台通用标准库的API，它本质是JVM平台对java.lang.String.format的封装。当你新增wasmJS构建目标后，Kotlin编译器会校验commonMain中的代码是否能在所有声明的平台上运行——由于wasmJS标准库没有实现这个函数，就会抛出「unresolved reference: format」错误。

解决办法 #

方案1：改用Kotlin通用格式化API #

如果是简单的文本格式化，直接用Kotlin原生的字符串模板即可满足需求：

val name = "Alice"
val age = 30
val message = "Name: $name, Age: $age"

如果需要日期、数字这类复杂格式化，可以引入kotlinx-datetime这类跨平台库来处理对应场景。

方案2：通过expect/actual适配多平台 #

自己封装跨平台的format函数，让不同平台使用各自的实现：

1. 在commonMain中定义预期函数：

expect fun String.format(vararg args: Any?): String

2. 在jvmMain中提供JVM平台的实际实现：

actual fun String.format(vararg args: Any?): String = java.lang.String.format(this, *args)

3. 在wasmJsMain中提供Wasm平台的适配实现：
   可以基于JavaScript能力实现，比如引入JS的sprintf，或者自己写基础逻辑：

actual fun String.format(vararg args: Any?): String {
    var formatted = this
    args.forEachIndexed { idx, value ->
        formatted = formatted.replace("%${idx + 1}", value.toString())
    }
    return formatted
}

这样commonMain中的代码就能正常调用format函数，编译器会自动匹配对应平台的实现。

KMP多平台通用标准库的确定机制 #

• KMP的通用标准库是Kotlin官方维护的、所有目标平台都支持的API集合，这些API在各平台有一致的行为定义，确保跨平台代码的兼容性。
• 平台专属API（比如依赖JVM的java包、依赖JS的浏览器API）不会被纳入通用标准库，这类API只能在对应的平台源集（如jvmMain、wasmJsMain）中使用。
• 当新增平台目标时，Kotlin编译器会对commonMain代码做全量校验：所有调用的函数必须属于通用标准库，或者有对应的expect/actual实现。如果某个API仅在部分平台支持，新增不支持的平台后就会触发编译错误。
• 官方会根据平台生态的完善程度逐步扩展通用标准库，但依赖特定平台特性的API始终需要开发者通过expect/actual机制自行适配。

内容的提问来源于stack exchange，提问作者kfaria