OkHttp ResponseBody 三种读取方法完整对比

一、底层统一基础三者底层共用同一份 TCP 网络流、同一套内核 TCP 缓冲区流只能读取一次任意一个方法调用后另外两个无法再使用。 内部源头都是 OkioBufferedSource只是对外封装、读取逻辑、生命周期控制不同。二、逐个拆解原理1.string()底层源码逻辑内部调用source()获取缓冲流循环读取直到exhausted() true把全部响应字节加载到内存字节数组转 UTF-8 字符串自动关闭流、释放 TCP 连接。核心特性读取模式一次性全量加载内存响应多大堆内存占用多大大响应极易 OOM控制权完全交给 OkHttp开发者无法干预分段读取连接读完立刻关闭不支持长连接 / 流式推送适用场景小接口、短 JSON、一次性返回结果禁止用于 SSE、大文件、长流2.source()底层源码逻辑直接返回包装好的BufferedSourceOkio 带缓冲输入流不会主动读取任何数据懒加载内置应用层 Buffer自动批量从内核缓冲区拉取数据减少用户态 / 内核态切换读取、关闭连接完全由开发者手动控制。核心特性读取模式按需分段读取读一段丢一段内存稳定丰富 APIreadUtf8Line()、readByteString()、exhausted()等流式专用方法连接不自动关闭可维持 TCP 长连接持续接收推送数据缓冲自带高性能分段缓冲无需手动包装适用场景SSE 流式输出、日志长推送、大文件分段下载、需要持续监听数据3.byteStream()底层源码逻辑内部先获取source()通过适配器转换为 JDK 原生InputStream对外暴露原生 InputStream无内置缓冲单次单字节 read 会频繁触发系统调用。核心特性读取模式原生字节流无分行、字符串快捷方法缓冲原生无缓冲想要缓冲必须手动套BufferedInputStream兼容性标准 Java IO 流适配老旧第三方工具、文件工具类连接需手动调用 close 关闭流释放连接适用场景兼容只接收InputStream的老旧 SDK、文件导出、第三方 IO 工具适配三、核心区别对照表维度string()source()byteStream()返回类型StringOkio BufferedSourceJDK InputStream内置缓冲有内部临时使用自带 Okio 缓冲无需手动包装读取方式一次性读完所有数据手动循环分段读取原生字节手动读取内存占用全量加载大数据 OOM 风险高固定小块缓冲内存可控无缓冲频繁读性能差连接生命周期读完自动关闭手动 close 才断开手动 close 才断开是否支持长连接 SSE❌ 会阻塞卡死✅ 完美适配⚠️ 可用但体验差便捷工具方法无直接出字符串readUtf8Line、exhausted 等只有基础 read ()设计目的快速获取短文本结果高性能流式处理兼容传统 Java IO四、关键原理总结共性三者数据源完全一致底层都依赖 Okio 缓冲流从内核 TCP 缓冲区拷贝数据本质差异string()封装了「读完全部 转字符串 关流」一站式逻辑source()直接暴露高性能缓冲流把读取、连接控制权交给开发者byteStream()是source()的兼容适配器转成老式 Java 标准流牺牲易用性换兼容性。性能优先级source()byteStream()手动加缓冲 byteStream()原生无缓冲