URLConnection.setReadTimeout控制已建立连接后读取响应数据的超时时间，单位毫秒；设为0表示无限等待，超时抛出SocketTimeoutException；它不控制DNS解析、连接建立或业务逻辑异常。

URLConnection.setReadTimeout 控制的是从已建立连接的服务器读取响应数据的最长等待时间，不是整个请求耗时，也不是连接建立阶段的时间。

它管什么：读取响应体的等待上限

当连接已成功建立（比如 TCP 握手完成、SSL 协商结束），但服务器迟迟不发送响应体内容（例如 JSON、HTML、图片流等），setReadTimeout 就开始计时。一旦超过设定毫秒数仍无数据可读，就会抛出 java.net.SocketTimeoutException。

• 设为 0 表示无限等待（不推荐，易导致线程挂起）
• 设为 5000 表示最多等 5 秒，期间哪怕只收到一个字节也算“有数据”，计时重置
• 超时触发点在 getInputStream().read(...) 或 getInputStream().readLine() 等阻塞读操作上

它不管什么：常见误解澄清

这个方法对以下情况完全无效：

• DNS 解析失败或耗时过长——这属于连接前环节，由系统或 DNS 缓存控制
• TCP 连接建立失败（如目标端口未开放、防火墙拦截）——这是 setConnectTimeout 的职责
• 服务器返回了 HTTP 状态码（如 200、500），但响应体为空或极小——此时读取几乎瞬时完成，不会触发 read timeout
• 应用层协议解析（如 JSON 解析异常、字符编码错误）——这些属于业务逻辑，不在网络超时范畴内

怎么设才合理：结合场景选值

没有统一标准值，需根据接口特性权衡：

• 内部微服务调用（局域网）：1000–3000 毫秒足够，响应快且稳定
• 第三方公开 API（如天气、支付回调）：5000–15000 毫秒较稳妥，容忍网络抖动和对方负载波动
• 大文件下载或流式响应（如视频分片）：不宜设太短，可配合分块读取 + 自定义心跳检测，避免误判
• 移动端弱网环境：建议不低于 8000 毫秒，并搭配重试机制（如指数退避）

必须配对使用的搭档：setConnectTimeout

单独设 readTimeout 不够安全。若服务器地址不可达或拒绝连接，connectTimeout 才是第一道防线：

• 典型组合：connection.setConnectTimeout(3000); connection.setReadTimeout(10000);
• 顺序无关，但建议在 connect() 或 getInputStream() 前完成设置
• 两者都未设置时，默认为无限等待，极易造成线程阻塞、资源耗尽