OkHttp 4.9.0版本中OkHttpURLConnection类不可用的原因及替代方案咨询

• 你引用的okhttp3.internal.huc.OkHttpURLConnection不属于可公开调用的API，不存在可供外部直接使用的迁移包路径：这类类从OkHttp 4.0版本开始，就彻底收回到了okhttp-urlconnection模块的内部访问范围，外部工程直接引用就会触发NoClassDefFoundError，和你遇到的运行时问题完全匹配。
• 3.13.1版本能直接new这两个类，本质是旧版本模块没有做严格的访问权限隔离，属于未被官方支持的旁路用法，从来不是设计上允许的公开调用方式。

最小改动适配：使用新版桥接API #

OkHttp 4.x没有移除URLConnection的桥接能力，只是把对外调用入口做了封装，不需要再手动构造内部类：

• 保留依赖配置：com.squareup.okhttp3:okhttp-urlconnection:4.9.0，这个模块在4.9.0版本依然正常维护。
• 把原来手动构造OkHttpURLConnection的逻辑，替换为模块提供的公开扩展方法：

// 提前初始化带CookieJar配置的OkHttpClient实例
OkHttpClient okHttpClient = builder
    .cookieJar(new JavaNetCookieJar(CookieHandler.getDefault()))
    .build();

protected URLConnection getStandardHTTPURLConnection(URL url) throws IOException {
    // 替代原来手动new内部类的逻辑
    return okHttpClient.openConnection(url);
}

说明：这个openConnection是okhttp-urlconnection模块为OkHttpClient添加的扩展方法，内部会自动根据传入URL的协议类型，返回对应HTTP/HTTPS实现的URLConnection，不需要再手动区分OkHttpURLConnection和OkHttpsURLConnection。

长期优化方向：迁移到OkHttp原生API #

如果业务场景允许，更推荐直接跳过URLConnection桥接层，用OkHttp原生请求逻辑开发：

• 可以移除额外的okhttp-urlconnection依赖，仅保留核心okhttp依赖即可减小包体体积。
• 原有Cookie配置逻辑可以完全复用，不需要做额外适配，原生API的请求性能、拦截器可控性都比桥接层更好。

• 不要尝试用反射加载内部类来兼容旧代码：OkHttp内部类的路径、构造方法参数在不同小版本中可能随时调整，反射方式没有长期稳定性保障，维护成本极高。
• 不要依赖桥接层的任何内部实现：okhttp-urlconnection模块本身就是为兼容存量老代码设计的过渡层，新业务开发优先使用OkHttp原生对外提供的公开API。

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