BodyHandlers.ofString() 返回乱码或空内容是因为默认按 UTF-8 解码，而服务端可能使用 GBK 等其他编码且未在 Content-Type 中声明 charset；应显式传入正确 Charset 或改用 ofInputStream() 手动解码。
BodyHandlers.ofString() 为什么返回乱码或空内容
Java 11+ 的 HttpResponse.BodyHandlers.ofString() 默认按 UTF-8 解码响应体，但接口实际编码可能是 GBK、ISO-8859-1 或未声明 charset 的 ISO-8859-1（尤其老系统）。一旦服务端没在 Content-Type 里写 charset=GBK，它就硬解成 UTF-8，结果就是中文变 或整段为空。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 先用
response.headers().firstValue("content-type")看服务端是否带了charset - 如果没带或不匹配，别直接用
ofString()，改用ofInputStream()+ 手动指定编码 - 最稳妥的写法：
HttpResponse.BodyHandler<String> handler = HttpResponse.BodyHandlers.ofString(StandardCharsets.UTF_8); // 显式传 Charset
BodyHandlers.ofFile() 写入失败的常见原因
BodyHandlers.ofFile() 看似一行搞定下载，但实际运行常报 java.nio.file.FileSystemException: Permission denied 或静默失败——根本没生成文件。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 目标路径父目录必须已存在，
ofFile()不会自动创建中间目录 - 确保进程有写权限，Windows 下注意是否被杀毒软件拦截，macOS/Linux 注意
umask和挂载选项 - 避免用相对路径如
new File("data/output.zip")，优先用绝对路径或Paths.get(...) - 若需覆盖已有文件，必须显式传
StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING，否则默认只允许创建新文件
如何安全地把响应体同时转成字符串和保存到文件
BodyHandlers 是单次消费的：用一次就没了。想既打印日志又存文件？不能对同一个 HttpResponse 调两次 body()。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
BodyHandlers.ofByteArray()拿原始字节数组，再分别转字符串、写文件 - 或者用
BodyHandlers.ofInputStream()，自己用try-with-resources分流处理（注意别提前 close） - 别用
BodyHandlers.ofString()后再试图从response.body()取流——已经 EOF - 大文件慎用
ofByteArray()，内存爆炸风险高；小响应（
BodyHandlers 在异步 HttpClient 中的陷阱
用 HttpClient.newBuilder().build().sendAsync(...) 时，BodyHandlers.ofString() 看似能用，但若响应体超大或网络慢，可能触发默认的 10 秒超时，抛出 java.util.concurrent.CompletableFuture$TimeoutException，而不是 HTTP 错误码。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 异步调用前务必设置超时：
HttpRequest.newBuilder() .timeout(Duration.ofSeconds(30)) // 覆盖默认 10s .GET().uri(...) -
BodyHandlers本身不控制超时，超时由HttpRequest.timeout()或HttpClient.Builder.connectTimeout()控制 - 异步场景下，
ofFile()的异常不会出现在sendAsync()的 CompletableFuture 中，而是发生在后续 write 阶段，需在thenApply里捕获 IOException
Content-Type: application/json 却用 GBK 编码返回，这种 case 必须靠抓包确认，不能只信 header。 
