绝不使用InputStreamReader无参构造方法，必须显式指定Charset；确保InputStream未被提前消费；文件优先用Files.newBufferedReader；网络流以Content-Type响应头charset为准。
避免 InputStreamReader 默认编码踩坑，核心就一条：**绝不使用无参构造方法**。它依赖 Charset.defaultCharset()，而这个值随操作系统和 JVM 启动参数浮动——Windows 常是 GBK，Linux/macOS 多为 UTF-8，一旦与源数据编码不匹配，乱码立刻出现。
必须显式指定 Charset 参数
无论数据来源是文件、网络响应还是内存字节流，都要主动传入确定的 Charset：
- 现代文本、JSON、HTTP API 响应 → 优先用
StandardCharsets.UTF_8（类型安全，无异常） - 老旧 Windows 记事本保存的“ANSI”文件 → 尝试
Charset.forName("GBK")或"GB2312" - 不确定编码时 → 先用
file -i（Linux/macOS）或 Notepad++ 的“编码检测”功能确认，再写死 Charset，别猜
别让 InputStream 被提前消费
InputStreamReader 是装饰器，只负责解码，不管理底层字节流位置。如果在创建它之前已调用过 inputStream.read()、mark() 或其他读取操作，流指针已偏移，解码就会从中间开始，导致开头乱码甚至 MalformedInputException：
- 确保传入的
InputStream是“干净”的——未被任何代码读取、标记或重置过 - 尤其注意 HTTP 客户端（如 OkHttp）是否已调用
response.body().bytes()或.string()，这些会消耗流
优先用 Files.newBufferedReader 替代手拼流
如果源头是文件，直接用 Files.newBufferedReader 更简洁、更安全：
立即学习“Java免费学习笔记（深入）”；
- 它强制要求传入
Charset，天然杜绝漏写编码的错误 - 内部已组合
FileInputStream → InputStreamReader → BufferedReader，资源自动管理（配合 try-with-resources） - 路径用
Path类型，自动适配不同系统的分隔符（/或\） - 示例：
Files.newBufferedReader(Paths.get("config.txt"), StandardCharsets.UTF_8)
网络流要以响应头为准，不是硬写 UTF-8
HTTP 响应的真实编码藏在 Content-Type 响应头里，比如 text/html; charset=GBK。不能凭经验硬写 UTF-8：
- 用
HttpURLConnection时，先解析conn.getContentType()提取 charset - 用 OkHttp 或 Apache HttpClient，它们通常已自动提取，但仍建议检查
response.body().string()输出是否正常 - 如果响应头缺失 charset，可结合 BOM（如
EF BB BF表示 UTF-8）或内容特征辅助判断
