ProtocolException: HTTP 表明请求违反HTTP协议规范，常见于手动设置请求头/体、setDoOutput(true)未配setDoInput(false)、误设Content-Length或Transfer-Encoding、空body却启用输出、或Android端响应行不合规。
Java里抛出 ProtocolException: HTTP 是什么信号
这不是网络不通，也不是服务器挂了，而是你发出去的HTTP请求本身被JVM的HttpURLConnection底层直接拦下了——它认为你构造的请求违反了HTTP协议基本规范。常见于手动拼接请求头、写入请求体、或复用连接时状态错乱。
HttpURLConnection 写完setDoOutput(true) 还要关掉setDoInput(false)
很多同学设了setDoOutput(true)（表示要发body），但忘了默认setDoInput(true)也开着，结果JVM在读响应前发现“你既想发又想收，但没按HTTP规则来”，就扔ProtocolException: HTTP。尤其在POST/PUT带body但不读响应时特别容易中招。
-
setDoOutput(true)和setDoInput(true)可以同时为true，但必须确保后续调用getInputStream()或getErrorStream()—— 不能只写不读 - 如果确定不读响应（比如发个埋点日志），显式调用
setDoInput(false)，否则JVM会尝试读响应头并校验状态码，失败就炸 - 别依赖“没写
getInputStream()就不会触发”——只要连接关闭或GC回收连接，底层仍可能尝试收包校验
手动设置Content-Length 或 Transfer-Encoding 的雷区
HttpURLConnection内部对这两个头极其敏感。你手动能设Content-Length，但它会在你调用getOutputStream()时偷偷覆盖；你设了Transfer-Encoding: chunked，而body长度固定，它又会拒绝发送。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 完全不要手动
setRequestProperty("Content-Length", ...)—— 交给JVM算，它会根据getOutputStream()写入的实际字节数填 - 避免手动设
Transfer-Encoding，HttpURLConnection不支持chunked上传（除非用setChunkedStreamingMode()） - 如果body为空（比如DELETE请求），别传
setDoOutput(true)，否则JVM会期待有body，却读到0字节，协议校验失败
Android上ProtocolException: Unexpected status line 的真实原因
这其实是同一类问题在Android低版本（特别是API 19以下）的变体：服务器返回了不符合RFC 7230的响应行，比如多空格、带BOM、或用了HTTP/1.0但返回了Transfer-Encoding: chunked。JVM底层解析器比OkHttp等库更死板。
立即学习“Java免费学习笔记（深入）”；
- 优先换用
OkHttpClient或Apache HttpClient，它们对非标响应容忍度高 - 如果必须用
HttpURLConnection，检查服务器返回的首行是否严格为HTTP/1.1 200 OK格式（空格数、大小写、末尾无不可见字符） - 抓包确认响应原始字节，用
xxd或Wireshark看有没有0xFEFF（BOM）或\r\r\n之类非法换行
最麻烦的不是报错本身，是它不告诉你具体哪条规则被违反——得靠排除法盯住请求头、body写入逻辑、连接复用状态这三个点反复试。很多人卡在“明明和服务端curl一样”，其实差的是一个没显式关掉的setDoInput，或者一次没清空的缓存输出流。
