为什么浏览器能跑的请求在 OkHttp 里却挂了？
在 Android 上用 OkHttp 发 HTTP 请求，遇到浏览器里一切正常的接口却返回 403、证书错误或者 Cookie 丢失，这种情况太常见了。其实不是你代码写错了，而是浏览器在背后帮你做了一大堆事情——自动管理 Cookie、跟随重定向、系统级证书校验、自动填充 User-Agent……而 OkHttp 只提供基本管道，你得自己把这些配置上。
OkHttp 核心原理
用好 OkHttp，关键在理解它的拦截器链。创建 OkHttpClient 时，最好用单例，因为它管理着连接池和全局的拦截器。一个请求会经过两层拦截器：应用拦截器和网络拦截器。应用层可以在请求发出前随意修改 Request，或在响应回来后对 Response 做手脚，但它看不到网络连接是否成功；网络层则刚好相反，能观察到真实的网络交互，但改不了原始请求。
内置的拦截器按顺序是：RetryAndFollowUpInterceptor（负责失败重试与重定向） → BridgeInterceptor（把用户请求转换成网络请求，添加 Content-Type、Host 等头，处理 gzip） → CacheInterceptor（检查缓存并决定是否走网络） → ConnectInterceptor（从连接池拿连接或建立新连接） → CallServerInterceptor（真正发送请求和读取响应）。了解这个顺序，排查问题时能少走很多弯路。
连接池默认空闲连接保持 5 分钟，同一个 Host 能复用 TCP 连接，这在频繁请求时效果显著。缓存策略则由 CacheInterceptor 根据响应头决定，过期了再验证，304 就直接用本地缓存。
这些机制是 OkHttp 性能出色的基础，但如果你在浏览器里不关心的细节，比如 Cookie 持久化，就需要通过 CookieJar 接口自己存储和发送。
Retrofit：简化还是添乱？
Retrofit 用动态代理把 Java/Kotlin 接口变成请求，底层还是走 OkHttp。配置 Retrofit 时，注意 BaseUrl、Converter 和 CallAdapter。默认只支持 Call 返回值，要是想用 RxJava 或者协程，得加对应的 CallAdapter。
一个容易踩坑的地方是线程切换：Retrofit 不会帮你把结果切回主线程。enqueue 异步回调默认在后台线程执行，你需要在回调里手动 post 到主线程更新 UI；如果用协程，配合 suspend 函数倒是能直接在 ViewModel 作用域里调用，但别忘了指定 dispatcher。
Netty 服务端：粘包和心跳
当你要自己写服务端，用 Netty 处理 TCP 连接时，粘包和拆包是绕不开的问题。TCP 是流式协议，没有消息边界，所以你发的两个包可能被合并成一个到达，或者一个包被拆成两半。解决方式无非三种：固定长度、加分隔符、或在消息头里夹带长度字段。我一般倾向后者，因为性能开销小，也不需要担心内容里出现分隔符。
长连接还得处理心跳和断线重连。Netty 的 IdleStateHandler 可以监测读写空闲，定期发一个轻量 ping 保活。断线重连要在客户端监听 ChannelInactive 事件，重新发起连接，最好配合指数退避避免疯狂重试。
实践中的取舍
最后，回到开头的问题：请求从浏览器挪到 OkHttp，需要做哪些调整？下表对比了几项关键差异：
| 特性 | 浏览器 | OkHttp |
|---|---|---|
| Cookie 管理 | 自动存储与发送 | 需手动设置 CookieJar |
| SSL 校验 | 系统级信任库 | 需配置 TrustManager |
| User-Agent | 自动填充 | 需手动添加 |
| 重定向 | 自动跟随 | 默认跟随，可配置关闭 |
实际项目中，我习惯用一个全局 OkHttpClient 实例，并在初始化时通过 Builder 统一配置 CookieJar、拦截器、连接超时和信任管理器。这样能避免每个 Request 都创建新客户端带来的资源浪费。安全上，如果接口对证书要求严格，建议开启证书固定，但前提是你得有办法在证书更新时及时升级客户端。
异常处理不能一刀切。除了基础的 IOException，最好区分网络类型（比如流量状态、WiFi 还是蜂窝网），也能帮助定位问题。有时候请求失败不是服务器挂掉，而是用户网络环境复杂。
理解这些差异和机制，就能少在'浏览器好好的，OkHttp 就是不行'的问题上浪费时间。
