socket.setsotimeout()仅控制后续阻塞式read()调用的单次等待上限，单位毫秒；必须在connect成功后、读取前设置，超时抛sockettimeoutexception，未设则默认无限等待。
因为超时机制只在阻塞式 I/O 操作真正开始等待时才被激活，而 setSoTimeout()（或底层 SO_RCVTIMEO）设置的是“后续一次或多次 read() 调用”的等待上限。如果在调用 InputStream.read() 之前没设好，JVM 就会按默认行为——无限等待，直到对端关闭、网络中断或系统级超时触发，此时已无法由应用层可控捕获和处理。
读取超时不是全局开关，而是每次 read 的“单程闹钟”
Java 的 setSoTimeout() 并不改变 Socket 的长期状态，它只影响下一次（或接下来连续的）阻塞读操作。一旦 read() 开始执行，内核就开始计时；若超时前没收到数据，就抛出 SocketTimeoutException。如果先调用了 read()，再调用 setSoTimeout()，那这次读早就卡住了，设置已失效。
底层依赖系统调用的语义一致性
在 Linux 等系统中，SO_RCVTIMEO 是通过 setsockopt() 设置到 socket 文件描述符上的，其作用范围严格限定于后续的 recv() 或 read() 系统调用。操作系统不会回溯已发起的系统调用，也不会为已进入阻塞态的线程动态注入超时逻辑。所以配置必须发生在系统调用发起前。
避免误判连接状态或掩盖真实问题
如果在流读取中途或之后设置超时，可能造成两种异常情况：
- 前几次
read()已经阻塞数分钟，此时设置超时毫无意义，程序实际早已“假死”； - 部分数据已读入缓冲区（比如 HTTP 响应头），但主体内容迟迟未到，若此时才设超时，容易把“慢响应”错当成“无响应”，提前中断合法通信。
Java 实现层面的约束
Socket.setSoTimeout() 方法的 Javadoc 明确指出：“This method must be called before the blocking operation begins.” 它内部直接映射到底层 socket 的 SO_RCVTIMEO 选项，而该选项对正在运行的 recv() 不生效。JVM 不做额外的线程监控或中断注入——它信任系统调用本身的超时语义。
