核心思路是绕过properties.load(inputstream)的iso-8859-1硬编码解码，改用utf-8显式解码：以inputstreamreader(is, utf_8)或stringreader(new string(bytes, utf_8))调用load(reader)，要求文件为utf-8无bom；禁用-dfile.encoding等全局设置；推荐idea启用透明转义保存。
核心思路不是“修复乱码”，而是绕过 Properties.load(InputStream) 的隐式 ISO-8859-1 解码路径，改用显式、可控的字节流 + UTF-8 解码流程。这在 JDK 8/11 等旧版本中稳定可靠，无需升级 JDK 或修改系统编码。
明确跳过 InputStream 路径，改用 Reader 加载
直接调用 props.load(Reader)，并确保该 Reader 使用 UTF-8 编码读取字节流。这样完全避开 Properties 内部对 ISO-8859-1 的硬编码依赖。
- 配置文件必须保存为 UTF-8 无 BOM 格式（Notepad++ 或 IDEA 可确认）
- 不使用
getResourceAsStream()后直接传给load(InputStream) - 而是包装成
InputStreamReader(is, StandardCharsets.UTF_8) - 若文件中中文是明文（如
name=张三），此方式开箱即用；若已是name=\u5f20\u4e09形式，也能正确识别，不影响兼容性
手动读取字节流 + 显式解码 + 转义还原（进阶控制）
当需要更高自由度（例如统一预处理、日志记录、或兼容混合编码场景），可完全接管加载过程：
- 用
Files.readAllBytes(Paths.get(...))或getResourceAsStream()获取原始字节 - 用
new String(bytes, StandardCharsets.UTF_8)得到 UTF-8 解码后的字符串 - 调用
Properties.load(new StringReader(decodedStr)) - 如需支持 native2ascii 转义（
\uXXXX），可额外调用Properties#unescape()或自行解析（JDK 内部有对应逻辑，可参考java.util.Properties#loadConvert）
避免反模式：不依赖 JVM 全局编码设置
不要试图通过 -Dfile.encoding=UTF-8 或 JAVA_TOOL_OPTIONS 来“修正” Properties 行为——它对 load(InputStream) 无效，且会污染其他组件（如文件 I/O、控制台输出）。
-
file.encoding不影响Properties.load(InputStream)的解码逻辑（该方法始终固定用 ISO-8859-1） - 全局设 UTF-8 可能导致读取 GBK 编码的旧日志、配置片段时出错
- 真正需要的是“按需指定”，而非“全局强推”
配套建议：properties 文件编写规范
从源头减少隐患，让流程控制更轻量：
- IDEA 中开启 Transparent native-to-ascii conversion（设置 → Editor → File Encodings），使中文自动转为
\uXXXX形式保存 - 这样即使后续用传统
load(InputStream)读取，也不会乱码（ISO-8859-1 可安全表示 ASCII 范围内的转义序列） - 团队协作时，统一使用转义格式，消除本地编码差异带来的风险
