2. OkHttp请求生命周期：拦截器链执行顺序、请求构造关键节点、响应处理与检查点

2.1 现象识别 – 隐私数据从哪些环节“溜走”？

隐私泄露往往不是一次性爆发，而是从请求生命周期的某个节点“渗漏”。常见的暴露现象包括：

• 日志中明文输出Authorization/Bearer 、Cookie、SessionID、身份证号等。
• 拦截器日志记录了完整的请求体或响应体（如JSON包含手机号、银行卡号）。
• 第三方SDK的拦截器在链中插队，未经审查便打印了请求所有Header。
• 重定向或302场景下，原始请求被携带到外部域名，造成跨域泄漏。

2.2 数据采集 – 如何捕获完整生命周期日志？

使用OkHttp内置的HttpLoggingInterceptor或自定义Interceptor，将拦截器分别添加到Application Interceptor和Network Interceptor两个位置，以区分前置和后置日志。

HttpLoggingInterceptor logging = new HttpLoggingInterceptor(message -> {
    // 采集时注意：生产环境需隐藏敏感字段
    System.out.println("AppInterceptor: " + message);
});
logging.setLevel(HttpLoggingInterceptor.Level.BODY);

OkHttpClient client = new OkHttpClient.Builder()
    .addInterceptor(logging)                 // Application Interceptor
    .addNetworkInterceptor(logging)          // Network Interceptor
    .build();

重要采集原则：

• 同时启用应用层和网络层的Interceptor，才能区分请求重定向前后的差异。
• 日志级别建议用HEADERS而非BODY，除非排查Body泄露风险。
• 采集过程必须处于调试或测试环境，不得在生产环境开启Body级别日志。

2.3 原因定位 – 拦截器链执行顺序与隐私泄露风险点

OkHttp请求生命周期由两条拦截器链组成，执行顺序如下（箭头表示数据流向）：

1. Application Interceptor链（用户自定义，先添加先执行）
   作用：处理请求前的统一逻辑（如添加公共Header、日志、重试）。
   风险：日志Interceptor若写在最前，将打印原始请求的全部信息。
2. Network Interceptor链（用户自定义，后添加先执行 → 离网络层更近）
   作用：处理实际网络I/O前后的转换（如压缩、缓存、重定向）。
   风险：重定向或重试时，Network Interceptor会多次触发，可能多次打印。
3. OkHttp内置核心Interceptor（不可修改）
   包括：重试/重定向、桥接Header、缓存、连接。

定位泄露点时，遵循以下判断规则：

2.4 修复动作 – 在关键节点“扎紧篱笆”

根据定位结果，执行以下修复之一或组合：

• 替换/移除日志Interceptor：在生产环境彻底移除HttpLoggingInterceptor，或改用仅输出Header的Level.HEADERS，并过滤Authorization、Cookie等Header。
• 自定义敏感字段过滤Interceptor：在日志输出前将敏感字段替换为[REDACTED]。
• 调整拦截器顺序：将敏感数据处理的Interceptor放在日志Interceptor之前，确保日志打印时数据已被脱敏。
• 使用白名单机制：只在明确授权的部分接口开启Body级日志。

// 自定义脱敏Interceptor示例
Interceptor sanitizer = chain -> {
    Request original = chain.request();
    // 只对日志用 – 不修改原始请求
    Request newRequest = original.newBuilder()
        .header("Authorization", "[REDACTED]")
        .header("Cookie", "[REDACTED]")
        .build();
    // 注意：此处是为了模拟日志脱敏，实际生产不应修改请求本身
    return chain.proceed(original); // 确保原始请求不变
};

2.5 复测 – 确认泄漏点已关闭

1. 在测试环境开启全量网络日志（包含Body），使用相同测试用例复现之前泄漏的场景。
2. 检查日志输出：Authorization、Cookie、X-Auth-等Header字段不得出现明文。
3. 检查响应体日志：如果响应包含敏感字段（如"phone":"138****1234"），应被脱敏或完全隐藏。
4. 检查重定向场景：原始不应出现于重定向后的请求日志中。
5. 使用自动化测试：编写单元测试，模拟拦截器链并断言日志输出不包含敏感关键词。

2.6 预防 – 将安全内建于拦截器链设计

从架构层面避免隐私泄漏，需在OkHttpClient构建阶段就建立安全基线：

• 禁止直接使用HttpLoggingInterceptor：始终用自定义Interceptor包装，内部实施字段白名单/黑名单。
• 固定拦截器顺序模板：

  client.newBuilder()
      .addInterceptor(new HeaderSanitizer())          // 1.先清洗Header
      .addInterceptor(new RequestBodySanitizer())     // 2.再清洗Body
      .addNetworkInterceptor(new LoggingInterceptor())// 3.最后记录日志（已清洗）
      .build();

• 定期审计拦截器链：通过client.interceptors().size()和networkInterceptors()检查有无新增未知拦截器。
• 使用OkHttp的EventListener：代替自定义Interceptor进行性能监控，避免修改请求/响应对象。

2.7 整理：拦截器链完整排查清单