InputStream.skip()在网络流中不可靠，因底层协议限制、缓冲机制或连接状态易截断，仅返回实际跳过字节数，不保证跳过指定数量。
InputStream.skip() 在网络流中跳过字节不可靠，容易因底层协议限制、缓冲机制或连接状态导致截断——它不保证跳过指定数量，只返回实际跳过的字节数。直接依赖返回值等于参数值，会引发后续读取错位、数据丢失或解析异常。
网络流中 skip() 为何常“跳不够”
SocketInputStream（网络流的典型实现）的 skip() 并不调用系统 lseek()，而是模拟跳过：内部分配缓冲区、反复 read() 并丢弃数据。这意味着：
- 每次 read() 可能只返回几十到几百字节，尤其在网络延迟高、TCP 窗口小或服务端分块发送时
- 若中途连接中断、超时或远端关闭写入，read() 返回 -1，skip() 提前终止，累计跳过字节数远小于目标
- 没有超时控制，可能长时间阻塞在某次 read() 上，而应用误以为“正在跳过”
截断风险的具体表现
当预期跳过 N 字节却只跳了 M（M
- HTTP 响应体解析失败：跳过响应头后本该读正文，结果从中间开始读，JSON/XML 解析器报 malformed
- 断点续传错位：客户端声明 Range: bytes=1000000-，服务端用 skip(1000000) 定位，但只跳了 982345 字节，后续传输内容整体偏移 17655 字节
- 协议帧错乱：如跳过固定长度魔数或长度字段后读 payload，跳过不足会导致 length 字段被截断，后续解析彻底失控
如何规避截断风险
不要信任单次 skip() 调用的结果，必须循环校验并主动处理异常：
- 用 while 循环调用 skip()，累计已跳字节数，直到达到目标或 read() 返回 -1
- 每次 skip() 后检查返回值：为 0 表示流暂不可读（可能阻塞或 EOF），需判断是否重试或报错
- 对网络流设置连接/读取超时（如 URLConnection.setConnectTimeout、setReadTimeout），避免无限等待
- 关键场景改用更可控方式：例如用 HttpURLConnection 的 Range 头由服务端完成偏移，而非客户端 skip()
替代 skip() 的更稳方案
对网络流，skip() 本质是“读丢弃”，无法真正 seek。可行替代路径有：
- 优先使用支持 Range 的 HTTP 协议语义，让服务端定位，客户端只读目标段
- 若必须本地跳过，用 BufferedInputStream 包装，并配合 mark()/reset() 控制回溯能力（注意 markSupported() 和 readlimit 限制）
- 自定义 SkipInputStream：封装循环逻辑 + 超时中断 + 明确异常分类（如 SkippedShortException）
- 彻底放弃 InputStream 抽象，改用 NIO 的 SocketChannel + ByteBuffer，手动管理读取与丢弃逻辑
