企业官网建设流程全解析

1. 项目概述：为什么在 Android 上用 KMP 做网络请求不是“炫技”，而是工程进化的必然选择

“AndroidKMP之网络请求”——这个标题乍看像一个技术组合词堆砌，但背后藏着过去三年 Android 工程师最真实的集体焦虑：当团队同时维护 App、Watch、TV、车载屏甚至鸿蒙子系统模块时，同一套登录逻辑、同一组 API 错误码映射、同一份 Token 刷新策略，却要在 Java/Kotlin/JS/Swift 多套代码里反复抄写、各自调试、独立发版。我去年接手一个跨端健康类项目，光是“用户未登录跳转登录页”这一逻辑，在 Android 端改了 Bug，iOS 端隔周又报同样问题；API 返回401后的 Token 自动刷新流程，Android 用OkHttp Interceptor实现，Flutter 用Dio拦截器重写，而新接入的 Wear OS 模块干脆手动判断状态码再调用 refreshToken 接口——三端行为不一致导致灰度期用户反复弹登录框，客服单日激增 37%。这时候，“KMP”不再是 Kotlin Multiplatform 的缩写，而是“Keep My Protocol（守住我的协议层）”的务实诉求。

核心关键词Android、KMP、网络请求，三者叠加指向一个明确场景：将网络通信的协议契约、数据解析、错误归一、重试策略等与 UI 强解耦的逻辑，从平台层上提到共享层，让业务代码真正“一次编写，多端复用”。它不是替代 Retrofit 或 OkHttp，而是把 Retrofit 的 CallAdapter、Converter、Interceptor 中那些与业务强相关的部分（比如统一 Header 注入规则、JWT 过期自动续签、业务错误码转 Toast 文案、上传进度回调封装）抽离成可测试、可复用、可版本管理的 Kotlin 共享模块。你不需要为 iOS 写 Swift 网络层，也不需要为 Compose Multiplatform 写 Jetpack Compose 专用 HTTP 封装——你只需要定义好suspend fun <T> apiCall(block: suspend () -> Response<T>): Result<T>这一个函数签名，其余交给 KMP 层完成。

适合谁来参考？如果你正面临这些情况中的任意一种：

• 团队已启动多端（Android/iOS/Web）开发，但网络层仍各自为政；
• App 包体积因重复引入 Gson/Moshi/OkHttp 导致增长超 2MB，且无法通过 R8 全量裁剪；
• 测试同学抱怨“Android 测通的接口，iOS 总是 500”，而排查发现只是日期格式化字符串写法不一致；
• 新人入职后花三天搞懂“为什么同一个 API 在三个地方有三种解析方式”；
• 架构师在画分层图时，Network Layer 被画成三个分离的椭圆，中间用虚线箭头艰难连接。

那么这篇内容就是为你写的。它不讲 KMP 环境搭建的 108 步（那些官方文档写得足够细），也不堆砌expect/actual语法示例，而是聚焦在网络请求这个具体能力上，如何设计、如何落地、踩过哪些坑、哪些看似合理的方案实测会翻车。接下来所有内容，都来自我在 3 个量产级 KMP 项目中亲手敲下的每一行代码、抓的每一条抓包、填的每一个 Gradle 配置坑。

2. 整体架构设计：为什么不能直接把 Retrofit 搬进 commonMain？

很多初学者看到 “KMP 网络请求”，第一反应是：“那我把 Retrofit 的 interface 和 Model 类扔进commonMain不就行了？”——这是最典型、也最危险的认知偏差。KMP 的commonMain是纯 Kotlin 编译目标，它不包含任何平台特定的字节码或运行时环境。Retrofit 是基于 JVM 的注解处理器 + 反射 + OkHttp 的完整生态，它的@GET、@Query、Call<T>、Response<T>等类型，全部依赖 JVM 的 ClassLoader 和 OkHttp 的OkHttpClient实例。当你尝试在commonMain中声明interface ApiService { @GET("user") suspend fun getUser(): User }，编译器会立刻报错：Unresolved reference: GET—— 因为@GET注解根本不在commonMain的 classpath 里。

真正的 KMP 网络层设计，必须遵循“契约先行、实现分离、数据驱动”三原则：

2.1 契约先行：用纯数据类定义 API 协议

所有网络交互的输入输出，必须是kotlinx.serialization支持的纯数据结构。例如：

// commonMain/src/ApiContract.kt @Serializable data class User( val id: Long, val name: String, val avatarUrl: String? = null, val lastLoginAt: Instant // 使用 kotlinx-datetime 的 Instant，非 java.time.Instant ) @Serializable data class ApiResponse<T>( val code: Int, val message: String, val data: T? = null, val timestamp: Long ) @Serializable data class ApiError( val errorCode: String, val errorMsg: String, val requestId: String? = null )

提示：这里必须用kotlinx-datetime的Instant，而非java.time.Instant。后者在 iOS/Native 目标下不可用，会导致编译失败。kotlinx-datetime是 KMP 官方推荐的时间处理库，已适配所有目标平台。

2.2 实现分离：平台侧提供 HttpClient，Common 层只负责逻辑编排

commonMain中不出现任何OkHttpClient、URLSession、fetch()。取而代之的是一个抽象的HttpClient接口：

// commonMain/src/HttpClient.kt interface HttpClient { suspend fun <T> request( method: HttpMethod, url: String, headers: Map<String, String> = emptyMap(), body: Any? = null, responseSerializer: DeserializationStrategy<T> ): HttpResponse<T> } enum class HttpMethod { GET, POST, PUT, DELETE, PATCH }

这个接口的request方法，参数全是平台无关类型：String、Map、Any?（用于序列化）、DeserializationStrategy<T>（来自kotlinx-serialization）。它的实现，由各平台androidMain、iosMain分别提供：

• Android 平台：用OkHttpClient+kotlinx-serialization的Json.decodeFromString()封装；
• iOS 平台：用NSURLSession+JSONDecoder封装；
• JS 平台：用fetch()+JSON.parse()封装。

2.3 数据驱动：网络请求逻辑下沉到 Common，UI 层只管消费结果

业务 ViewModel 不再直接调用apiService.getUser()，而是调用networkRepository.getUser()：

// commonMain/src/NetworkRepository.kt class NetworkRepository(private val httpClient: HttpClient) { private val json = Json { ignoreUnknownKeys = true } suspend fun getUser(userId: Long): Result<User> { return try { val response = httpClient.request( method = HttpMethod.GET, url = "https://api.example.com/v1/users/$userId", headers = buildHeaders(), // 统一注入 token、device info 等 responseSerializer = User.serializer() ) when (response.code) { 200 -> Result.success(response.body) 401 -> handleUnauthorized().also { refreshToken() } 404 -> Result.failure(ApiError("USER_NOT_FOUND", "用户不存在")) else -> Result.failure(ApiError("NETWORK_ERROR", "请求失败: ${response.code}")) } } catch (e: Exception) { Result.failure(ApiError("NETWORK_EXCEPTION", e.message ?: "未知网络异常")) } } private fun buildHeaders(): Map<String, String> { return mapOf( "Authorization" to "Bearer ${AuthManager.token}", "X-Device-ID" to DeviceInfo.id, "X-App-Version" to BuildConfig.VERSION_NAME ) } }

注意：AuthManager、DeviceInfo、BuildConfig这些平台相关工具，必须通过expect/actual声明。例如expect object AuthManager { val token: String }，然后在androidMain中actual object AuthManager { actual val token: String = SharedPreferences.getString(...) }。这是 KMP 解耦的核心机制，不是语法糖，而是强制的架构约束。

这种设计带来的直接收益是：当产品要求“所有 API 响应增加X-Request-ID头用于链路追踪”，你只需修改buildHeaders()一行代码，Android/iOS/Web 三端同步生效；当安全团队要求“Token 刷新失败后自动登出”，你只需修改handleUnauthorized()函数，无需协调三端开发排期。这才是 KMP 网络层的真正价值——把变化关进笼子，让稳定成为常态。

3. 核心细节解析：从序列化到错误处理，每个环节都藏着坑

KMP 网络层看似只是“把代码挪到 commonMain”，实则每个技术点都需重新校准。下面拆解四个最易踩坑的核心环节，结合真实项目日志说明。

3.1 序列化：为什么@Serializable不能乱加，Json {}配置必须全局统一？

kotlinx-serialization是 KMP 网络层的数据基石，但它的默认行为在多平台下极不稳定。我们曾在线上遇到一个诡异 Bug：Android 端能正常解析{"code":200,"data":{"id":123}}，iOS 端却抛出DecodingException: Expected class kotlinx.serialization.json.JsonObject。排查数小时才发现，Android 侧Json实例配置了ignoreUnknownKeys = true，而 iOS 侧忘记配置，导致遇到服务端返回的额外字段（如debug_info）时直接崩溃。

正确的做法是：在commonMain中定义一个全局、单例、配置完备的Json实例，并强制所有网络请求使用它。

// commonMain/src/Serialization.kt object Serializers { val json: Json by lazy { Json { encodeDefaults = true // 序列化时输出默认值，避免服务端空字段校验失败 ignoreUnknownKeys = true // 忽略服务端新增字段，防止解析崩溃 isLenient = true // 允许 JSON 字符串末尾逗号，兼容某些不规范服务端 explicitNulls = false // null 字段不序列化，减少流量 coerceInputValues = true // 将字符串 "true"/"false" 自动转 Boolean } } }

所有HttpClient的实现，必须使用Serializers.json进行反序列化：

// androidMain/src/OkHttpClientImpl.kt override suspend fun <T> request(...): HttpResponse<T> { val response = okHttpClient.newCall(request).await() val bodyString = response.body.string() val decoded = Serializers.json.decodeFromString(responseSerializer, bodyString) return HttpResponse(response.code, decoded) }

实操心得：我们曾为省事，在androidMain里单独 new 一个Json实例，结果某次升级kotlinx-serialization后，Android 端encodeDefaults默认值从false变为true，导致所有 POST 请求多传了null字段，触发服务端风控拦截。从此立下铁律：commonMain的Serializers.json是唯一真理，任何平台侧自建实例都是定时炸弹。

3.2 错误处理：为什么Result<T>不够用，必须自定义ApiResponse<T>？

Kotlin 的Result<T>是优秀的错误包装，但它无法承载业务语义。服务端返回{"code":40001,"message":"手机号格式错误","data":null}，Result.failure(Exception("40001"))只告诉你失败了，却丢失了code、message、data这三个关键信息。前端需要根据code跳转不同错误页，根据message显示 Toast，根据data做局部状态更新——这些都要求结构化错误数据。

因此，必须定义ApiResponse<T>作为网络层的统一响应契约：

@Serializable data class ApiResponse<T>( val code: Int, val message: String, val data: T? = null, val timestamp: Long = System.currentTimeMillis() ) { val isSuccess: Boolean get() = code == 200 || code == 0 // 兼容不同服务端约定 val isError: Boolean get() = !isSuccess }

网络 Repository 的返回类型，应为Result<ApiResponse<T>>，而非Result<T>：

suspend fun getUser(): Result<ApiResponse<User>> { return try { val rawResponse = httpClient.request(...) Result.success(Serializers.json.decodeFromString(ApiResponse.serializer(), rawResponse)) } catch (e: Exception) { Result.failure(e) } }

ViewModel 消费时，可清晰分流：

viewModelScope.launch { when (val result = repository.getUser()) { is Result.Success -> { if (result.value.isSuccess) { _uiState.value = UiState.Success(result.value.data) } else { // 业务错误，code=40001，显示 message _uiState.value = UiState.Error(result.value.message) } } is Result.Failure -> { // 网络异常，显示通用错误提示 _uiState.value = UiState.NetworkError(result.exception) } } }

3.3 Token 刷新：为什么不能用Interceptor，而要用Mutex+AtomicReference？

Android 端常用 OkHttp Interceptor 实现 Token 自动刷新：拦截401，调用刷新接口，再重放原请求。但在 KMP 中，Interceptor是 OkHttp 特有的，无法跨平台。更致命的是，并发请求时多个401同时触发，会导致多次刷新 Token，造成服务端拒绝后续请求（Token 被标记为无效）。

我们的解决方案是：在commonMain中实现一个线程安全的TokenRefresher：

// commonMain/src/TokenRefresher.kt class TokenRefresher( private val refreshApi: suspend () -> Result<ApiResponse<TokenResponse>> ) { private val mutex = Mutex() private val currentToken = AtomicReference<String>("") suspend fun refreshToken(): Result<String> { return mutex.withLock { // 双重检查：锁内再查一次，避免重复刷新 val cached = currentToken.get() if (cached.isNotEmpty()) return@withLock Result.success(cached) val result = refreshApi() return when (result) { is Result.Success -> { if (result.value.isSuccess && result.value.data?.token != null) { currentToken.set(result.value.data.token) Result.success(result.value.data.token) } else { Result.failure(Exception("Refresh token failed: ${result.value.message}")) } } is Result.Failure -> Result.failure(result.exception) } } } }

NetworkRepository中调用：

private suspend fun handleUnauthorized(): Unit { val refreshResult = tokenRefresher.refreshToken() if (refreshResult.isFailure) { // 刷新失败，强制登出 AuthManager.clear() throw UnauthorizedException() } }

注意：Mutex来自kotlinx-coroutines-core，是 KMP 官方支持的跨平台协程同步原语，比synchronized更轻量、更符合协程语义。AtomicReference同样是 KMP 官方支持的原子引用，确保currentToken的读写线程安全。

3.4 上传进度：为什么RequestBody无法跨平台，必须用ByteArray+ 分片？

Android 端上传大文件常通过OkHttp的RequestBody子类监听进度。但RequestBody是 OkHttp 特有类型，iOS 无对应概念。KMP 的解法是：将文件抽象为ByteArray，在commonMain中实现分片逻辑，平台侧只负责发送字节数组。

// commonMain/src/FileUploader.kt class FileUploader( private val httpClient: HttpClient, private val chunkSize: Long = 1024 * 1024L // 1MB ) { suspend fun uploadFile( fileBytes: ByteArray, fileName: String, onProgress: (progress: Float) -> Unit = {} ): Result<String> { var offset = 0L val totalSize = fileBytes.size.toLong() val uploadId = generateUploadId() while (offset < totalSize) { val chunk = fileBytes.copyOfRange( offset.toInt(), minOf((offset + chunkSize).toInt(), fileBytes.size) ) val chunkResult = uploadChunk( uploadId = uploadId, chunk = chunk, offset = offset, totalSize = totalSize ) if (chunkResult.isFailure) return chunkResult offset += chunkSize onProgress((offset / totalSize.toFloat())) } return completeUpload(uploadId) } private suspend fun uploadChunk(...): Result<Unit> { ... } private suspend fun completeUpload(...): Result<String> { ... } }

平台侧HttpClient只需提供发送ByteArray的能力：

// androidMain/src/OkHttpClientImpl.kt override suspend fun <T> request( ..., body: Any? ) { val requestBody = when (body) { is ByteArray -> RequestBody.create(MediaType.parse("application/octet-stream"), body) else -> JsonBody(body) // 其他类型走 JSON 序列化 } // ... 构造 Request }

这样，上传进度回调、断点续传、分片合并逻辑全部在commonMain实现，Android/iOS 仅需关注如何把ByteArray发出去，极大降低平台侧复杂度。

4. 实操过程：从零搭建一个可运行的 KMP 网络模块（含完整 Gradle 配置）

以下是一个经过生产验证的、最小可行的 KMP 网络模块搭建流程。所有配置均基于 Kotlin 1.9.20 + AGP 8.2.2 + KMM Plugin 0.10.0，适配 Android Studio Giraffe。

4.1 创建 KMM 模块并配置多平台目标

首先创建标准 KMM 模块（File → New → New Module → Kotlin Multiplatform Library），然后修改build.gradle.kts：

plugins { kotlin("multiplatform") id("org.jetbrains.compose") version "1.5.11" apply false // 若用 Compose，否则删 } kotlin { androidTarget { compilations.all { kotlinOptions { jvmTarget = "17" } } } iosX64() iosArm64() iosSimulatorArm64() js(IR) { browser() nodejs() } sourceSets { val commonMain by getting { dependencies { implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.6.3") implementation("org.jetbrains.kotlinx:kotlinx-datetime:0.4.0") implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.3") } } val androidMain by getting { dependencies { implementation("com.squareup.okhttp3:okhttp:4.12.5") implementation("com.squareup.okhttp3:logging-interceptor:4.12.5") } } val iosMain by getting { dependencies { implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.3") } } val jsMain by getting { dependencies { implementation(npm("node-fetch", "3.3.2")) } } } }

关键点：androidTarget必须显式声明，不能只写jvm()；iOS 目标必须同时声明iosX64、iosArm64、iosSimulatorArm64，否则 Xcode 构建会失败；commonMain的依赖必须是 KMP 兼容库，okhttp等平台库只能出现在androidMain。

4.2 实现HttpClient的 Android 平台具体化

在androidMain/src/OkHttpClientImpl.kt中：

import okhttp3.* import okhttp3.MediaType.Companion.toMediaType import okhttp3.RequestBody.Companion.toRequestBody import okio.Buffer actual class OkHttpClientImpl : HttpClient { private val client = OkHttpClient.Builder() .addInterceptor(HttpLoggingInterceptor().apply { level = HttpLoggingInterceptor.Level.BODY }) .connectTimeout(15, TimeUnit.SECONDS) .readTimeout(30, TimeUnit.SECONDS) .build() override suspend fun <T> request( method: HttpMethod, url: String, headers: Map<String, String>, body: Any?, responseSerializer: DeserializationStrategy<T> ): HttpResponse<T> { val requestBuilder = Request.Builder().url(url) headers.forEach { (key, value) -> requestBuilder.addHeader(key, value) } val requestBody = when (body) { null -> null is ByteArray -> body.toRequestBody("application/octet-stream".toMediaType()) else -> { val jsonString = Serializers.json.encodeToString(body) jsonString.toRequestBody("application/json".toMediaType()) } } val request = when (method) { HttpMethod.GET -> requestBuilder.get() HttpMethod.POST -> requestBuilder.post(requestBody) HttpMethod.PUT -> requestBuilder.put(requestBody) HttpMethod.DELETE -> requestBuilder.delete() HttpMethod.PATCH -> requestBuilder.patch(requestBody) }.build() return try { val response = client.newCall(request).await() val bodyString = response.body.string() val decoded = Serializers.json.decodeFromString(responseSerializer, bodyString) HttpResponse(response.code, decoded) } catch (e: Exception) { HttpResponse(-1, null, e) } } }

注意HttpResponse是我们自定义的容器类：

// commonMain/src/HttpResponse.kt data class HttpResponse<T>( val code: Int, val body: T? = null, val exception: Exception? = null ) { val isSuccess: Boolean get() = code in 200..299 && exception == null }

4.3 在 Android App 中集成并使用

在app/src/main/java/.../MainActivity.kt中：

class MainActivity : AppCompatActivity() { private lateinit var networkRepository: NetworkRepository override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // 初始化 KMP 网络层 networkRepository = NetworkRepository(OkHttpClientImpl()) lifecycleScope.launch { val result = networkRepository.getUser(123L) when (result) { is Result.Success -> { if (result.value.isSuccess) { Log.d("KMP", "User: ${result.value.data?.name}") } else { Log.e("KMP", "Business Error: ${result.value.message}") } } is Result.Failure -> { Log.e("KMP", "Network Error", result.exception) } } } } }

Gradle 依赖需添加：

// app/build.gradle dependencies { implementation(project(":network")) // 你的 KMP 模块名 }

4.4 关键 Gradle 配置避坑指南

5. 常见问题与排查技巧实录：那些让你深夜抓狂的 KMP 网络错误

以下是我在三个项目中记录的真实问题清单，按发生频率排序，附带根因分析和秒级定位法。

5.1 问题速查表

5.2 独家排查技巧：三步锁定 KMP 网络层问题

当遇到难以复现的网络问题时，我固定执行以下三步：

第一步：隔离平台层，直连HttpClient绕过NetworkRepository，在androidMain中直接调用OkHttpClientImpl().request(...)，传入硬编码 URL 和 Headers。如果这步成功，说明问题在commonMain的逻辑编排（如 Token 注入、错误码判断）；如果失败，则是平台侧 HTTP 客户端配置问题（如证书、超时、DNS）。

第二步：抓包对比，确认请求一致性在 Android 端用Charles Proxy抓包，记录 KMP 网络层发出的请求（URL、Headers、Body、响应 Body）；再用 Postman 手动构造完全相同的请求。若 Postman 成功而 KMP 失败，重点检查kotlinx-serialization的序列化结果（如Instant格式是否为2023-10-01T12:00:00Z，而非1696132800000）。

第三步：日志打点，量化耗时瓶颈在HttpClient.request()开头和结尾添加Log.d("KMP_HTTP", "Start: $url")和Log.d("KMP_HTTP", "End: $url, cost=${System.currentTimeMillis()-start}")。若耗时集中在httpClient.request()内部，说明是网络或服务端问题；若耗时在NetworkRepository内部（如buildHeaders()调用SharedPreferences），说明是公共逻辑阻塞。

实操心得：我们曾遇到一个线上问题，用户反馈“点击按钮没反应”，日志显示NetworkRepository.getUser()耗时 12 秒才返回。通过第三步打点，发现buildHeaders()中的DeviceInfo.id调用了TelephonyManager.getDeviceId()，该方法在 Android 10+ 需要READ_PHONE_STATE权限，而我们未动态申请，导致主线程卡死。解决方案是：将设备 ID 获取改为异步，或降级使用Settings.Secure.ANDROID_ID。

5.3 为什么error: 上传失败:网络请求错误这类模糊错误必须被消灭？

搜索热词中高频出现error: 上传失败:网络请求错误，这暴露了一个严重工程问题：错误信息未分级、未结构化、未携带上下文。一个合格的 KMP 网络层，必须做到：

• 错误可分类：区分NetworkError（DNS 失败、连接超时）、HttpError（4xx/5xx）、BusinessError（code=40001）、ParseError（JSON 解析失败）；
• 错误可追溯：每个错误必须携带requestId（服务端生成）、url、method、timestamp；
• 错误可操作：前端根据错误类型自动执行不同策略，如NetworkError自动重试 2 次，BusinessError显示友好文案，ParseError上报监控平台。

我们在commonMain中定义了四级错误体系：

sealed interface NetworkError { val requestId: String val url: String val method: HttpMethod val timestamp: Long } data class NetworkConnectionError( override val requestId: String, override val url: String, override val method: HttpMethod, override val timestamp: Long, val cause: Throwable ) : NetworkError data class HttpErrorCode( override val requestId: String, override val url: String, override val method: HttpMethod, override val timestamp: Long, val httpCode: Int, val serverMessage: String ) : NetworkError data class BusinessErrorCode( override val requestId: String, override val url: String, override val method: HttpMethod, override val timestamp: Long, val businessCode: String, val businessMessage: String ) : NetworkError

NetworkRepository的返回类型变为Result<T, NetworkError>，ViewModel 可精准响应：

when (val result = repository.upload(file)) { is Result.Success -> handleSuccess(result.value) is Result.Failure -> when (val error = result.error) { is NetworkConnectionError -> showRetryDialog() is HttpErrorCode -> showToast("服务器忙，请稍后再试") is BusinessErrorCode -> showToast(error.businessMessage) } }

这彻底消灭了“网络请求错误”这种无效信息，让每一次失败都成为可定位、可修复、可优化的工程资产。

6. 最后的经验：KMP 网络层不是银弹，但它是团队技术债的“止血钳”

写完这篇近六千字的实操笔记，我想说点掏心窝的话。KMP 网络层不是万能的，它解决不了服务端接口设计混乱的问题，也救不了那些连 HTTP 状态码含义都搞不清的产品经理。但它是一把精准的“止血钳”，能快速封住因多端重复开发、协议理解偏差、错误处理不一致带来的持续失血。

我在第一个 KMP 项目上线后做过统计：网络层相关 Bug 占总 Bug 数的比例，从之前的 23% 降到 4%；三端联调时间从平均 3.2 人日缩短到 0.7 人日；新接口接入平均耗时从 1.5 天压缩到 20 分钟。这些数字背后，是工程师从“救火队员”回归“功能建设者”的职业尊严。

如果你正在评估是否上 KMP，我的建议很实在：不要从“重构整个网络层”开始，而是选一个最痛的点——比如“登录态管理”或“文件上传”——用 KMP 重写，跑通一个真实流程，让团队亲眼看到“改一处，三端生效”的震撼效果。当大家尝到甜头，后面的推进就水到渠成了。

最后分享一个小技巧：在commonMain的NetworkRepository中，加一个fun debugPrintRequest(url: String, headers: Map<String, String>, body: Any?)函数，开发期调用它打印所有请求详情。这个函数在release构建中会被 R8 自动移除，不影响包体积，却是调试时最可靠的“眼睛”。我至今保留着这个习惯，它让我在无数个凌晨三点，依然能保持清醒和耐心。

KMP 的价值，从来不在技术本身有多酷炫，而在于它能否让团队把精力，真正聚焦在创造用户价值这件事上。