Properties.load()默认ISO-8859-1解码致中文乱码，应使用InputStreamReader指定UTF-8；store()不保证顺序且线程不安全，需用LinkedHashMap或ConcurrentHashMap替代；Spring Boot中优先用@ConfigurationProperties而非手动读写。

Properties.load() 读取配置时中文乱码怎么办

Java 的 Properties 默认用 ISO-8859-1 解码，读取含中文的配置文件（如 UTF-8 编码的 app.properties）会显示为问号或方块。这不是文件损坏，是编码不匹配。

• 最稳妥做法：改用 InputStreamReader 指定 UTF-8，再传给 load()，例如：

  try (InputStream is = Files.newInputStream(Paths.get("app.properties"));
       Reader reader = new InputStreamReader(is, StandardCharsets.UTF_8)) {
      props.load(reader);
  }

• 别依赖 IDE 自动保存为 UTF-8 就万事大吉——Windows 记事本另存为 UTF-8 会带 BOM，Properties 无法跳过，导致首行 key 解析失败
• 如果必须用默认 load(InputStream)，就得提前把中文转成 Unicode 转义（如 name=\u4f60\u597d），但维护成本高，不推荐

Properties.store() 写入后配置项顺序混乱

Properties 继承自 Hashtable，内部无序；JDK 1.8+ 虽在 store() 中按字母序输出 key，但这是副作用，不是保证行为。你不能靠它维持“数据库配置在前、日志配置在后”的排版。

• 若需固定顺序，改用 LinkedHashMap + 手动拼接字符串写入，或引入第三方库如 Apache Commons Configuration
• store() 生成的注释行（#开头）和空行会被忽略，不要指望用空行分隔模块
• 调用 store() 前没调用 setProperty() 或直接操作 put()，可能导致部分键值未写入——put() 插入的是 Object 类型，store() 只序列化 String 类型的键值对

在 Spring Boot 里还该手写 Properties 读写吗

不该。Spring Boot 的 @ConfigurationProperties 和 @Value 已封装好类型安全、校验、环境隔离等能力，硬套原生 Properties 反而绕路。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 直接用 ResourceLoader 加载 classpath:xxx.properties 再 parse，等于放弃 Spring 的配置绑定机制和 profile 支持
• 如果只是临时读一个外部配置文件（比如运维给的独立 secret.properties），可用 Properties + Resource，但记得加异常兜底——文件不存在或权限不足时 load() 抛 IOException，别让它崩掉整个启动流程
• System.getProperties() 和 System.getenv() 是只读快照，修改它们不影响运行时行为，也别试图拿它们当配置中心用

Properties 线程安全吗？并发读写会出什么问题

不安全。Properties 方法本身没加锁，多个线程同时 setProperty() 和 store() 可能导致写入内容错乱、部分 key 丢失，甚至 ConcurrentModificationException。

立即学习“Java免费学习笔记（深入）”；

• 读多写少场景：用 Collections.synchronizedMap(new Properties()) 包一层，但注意 entrySet().iterator() 这类复合操作仍需手动同步
• 写操作频繁（比如动态刷新配置），建议换成 ConcurrentHashMap<string string></string>，自己管理持久化逻辑，别被 Properties 的历史包袱绑住
• 别在静态块里初始化全局 Properties 实例并供多处修改——看似方便，实则埋下竞态雷

真正麻烦的从来不是读写动作本身，而是默认编码、隐式类型转换、以及你以为它有序/线程安全的错觉。