当 OkHttp 因 SSL Pinning 验证失败（如证书哈希不匹配）而中断请求时，chain.proceed(request) 会直接抛出 SSLPeerUnverifiedException 或 IOException，而非返回 null 响应；正确做法是在拦截器中用 try-catch 捕获异常，并从中提取错误信息用于调试或用户提示。
当 okhttp 因 ssl pinning 验证失败（如证书哈希不匹配）而中断请求时，`chain.proceed(request)` 会直接抛出 `sslpeerunverifiedexception` 或 `ioexception`，而非返回 `null` 响应；正确做法是在拦截器中用 `try-catch` 捕获异常，并从中提取错误信息用于调试或用户提示。
在 React Native Android 端集成 SSL Pinning（例如通过 CertificatePinner）后，开发者常期望在证书校验失败时获得可观测的反馈（如日志、Toast 提示或上报监控），而非让请求静默失败。但需明确一个关键事实：OkHttp 的证书钉扎验证发生在连接建立阶段（即 chain.proceed() 内部的 TLS 握手环节），早于网络拦截器能访问到 Response 对象的时机。因此，chain.proceed(request) 不会返回 null，而是直接抛出运行时异常——典型如：
- javax.net.ssl.SSLPeerUnverifiedException: “Certificate pinning failure…”
- java.io.IOException: “Failed to connect to …”（底层封装后的异常）
这意味着，若不在拦截器中显式捕获异常，整个调用链将中断，后续日志（如 System.out.println("Intercepted response: ...")）根本不会执行，也无法对失败场景做任何响应。
✅ 正确实现：在拦截器中捕获并处理证书异常
以下为推荐的 CustomInterceptor 实现，兼顾健壮性与可观测性：
public class CustomInterceptor implements Interceptor {
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
System.out.println("My Client::: Intercepted request: " + request.url());
try {
Response response = chain.proceed(request);
System.out.println("My Client::: Intercepted SUCCESS response: " + response.code());
return response;
} catch (SSLPeerUnverifiedException e) {
// 明确捕获证书钉扎失败异常
String errorMsg = "SSL Pinning failed for " + request.url() + ": " + e.getMessage();
System.err.println("My Client::: PINNING ERROR → " + errorMsg);
// 可选：上报至 Crashlytics / Sentry，或触发 RN 端事件
// sendToReactNative("ssl_pinning_failure", errorMsg);
throw e; // 保持异常传播，避免掩盖问题
} catch (IOException e) {
// 捕获其他连接层异常（如网络不可达、超时等）
System.err.println("My Client::: Network error: " + e.getMessage());
throw e;
}
}
}⚠️ 注意事项与最佳实践
- 不要吞掉异常：catch 后务必 throw e 或重新包装抛出（如 throw new RuntimeException("SSL pinning failed", e)）。否则 Axios 在 JS 层将收不到错误，表现为请求无响应或 timeout，极大增加排查难度。
- 异常类型优先匹配 SSLPeerUnverifiedException：它是 OkHttp 在证书钉扎失败时抛出的最具体异常（继承自 SSLException），比泛化 Exception 更精准、更利于诊断。
- 日志需包含 URL 和原始异常消息：e.getMessage() 通常已含 pinned certificate hash、server certificate hash 等关键比对信息，是定位配置错误的核心依据。
- 避免在 catch 中返回伪造 Response：如构造 Response.Builder().code(500).build() 并返回——这会欺骗上层（如 Axios）认为请求“成功完成”，违背 SSL Pinning 的安全语义，且导致业务逻辑误判。
- React Native 端联动建议：可通过 ReactContext 触发原生模块事件（如 sendEvent("OnSslPinFailure", map)），在 JS 层监听并展示友好提示或引导用户检查网络环境。
? 替代方案思考：是否必须原生实现？
当前因缺乏支持 Axios 的跨平台 SSL Pinning 库而选择 Android 原生接入，是合理权衡。但需注意：
- iOS 端需同步实现 URLSessionDelegate 的 didReceiveChallenge 逻辑，确保双端行为一致；
- 若未来项目转向更可控的网络栈（如使用 react-native-network-interceptor + 自定义 fetch 封装），可探索在 JS 层统一处理证书错误回调（仍需原生能力支撑）。
总之，SSL Pinning 的失败不是“无响应”，而是“有异常”——拥抱异常、精准捕获、透明记录，才是构建可信安全通信的基础。
