Socket读超时仅对未开始的read()生效，必须在connect后、首次read前调用setSoTimeout()；超时抛出SocketTimeoutException后Socket仍连接，需主动处理否则假死；设为0或不设将导致永久阻塞。
因为 setSoTimeout() 只对尚未开始的读操作生效，一旦 InputStream.read() 或 BufferedReader.readLine() 这类阻塞调用已发起，超时设置就无法中断它——线程会继续卡住，直到数据到达、连接关闭或系统底层强制终止。防死锁的关键，是把超时“设在等待之前”，而不是“等卡住了再补救”。
超时机制只作用于“将要发生的读”，不干预“正在发生的读”
Socket 的读超时不是实时监控器，而是一次性开关：调用 setSoTimeout(ms) 后，**下一次及之后所有未开始的 read() 调用**才会受该毫秒值约束。如果先调用了 read()，再设置超时，这次 read 仍会无限等待（除非连接断开）。JDK 不提供运行中修改阻塞读行为的能力。
连接建立后、首次读取前是唯一安全设置时机
这个窗口期必须严格遵守，常见错误顺序会导致超时失效：
- ❌ new Socket() → setSoTimeout() → connect() → read()（connect 前设置，部分 JDK 忽略）
- ❌ new Socket(host, port) → read() → setSoTimeout()（read 已启动，超时无效）
- ✅ new Socket() → connect(addr, timeout) → setSoTimeout(5000) → read()（推荐：连接与读超时分离控制）
超时抛异常 ≠ 连接断开，但没处理就会隐性卡死
SocketTimeoutException 抛出时，Socket 对象本身仍处于 CONNECTED 状态，输入流也未关闭。若捕获后不做任何处理（比如没重试、没 close、也没继续 read），下一次 read() 会再次触发相同超时逻辑——表面看是“反复超时”，实质是业务逻辑遗漏了状态推进，最终表现为假死。
不设超时或设为 0，等于主动放弃控制权
setSoTimeout(0) 表示无限等待；不调用则沿用系统默认（通常是 0）。在网络抖动、服务端 hang 住、中间设备静默丢包等场景下，线程将永久阻塞在 read() 上，占用线程资源、拖垮连接池、引发雪崩。这不是理论风险，而是生产环境高频故障源。
