try-with-resources 与 Builder 模式职责分离：Builder 负责构建对象，try-with-resources 负责自动释放资源；只需确保 build() 返回的实例实现 AutoCloseable，无需修改 Builder 本身。
try-with-resources 和 Builder 模式解决的是不同层面的问题，它们不直接耦合，但可以在同一业务场景中自然配合使用：前者负责资源的自动释放（如文件流、数据库连接），后者负责复杂对象的安全、可读构建。关键在于——Builder 构建的对象本身不一定是资源，但如果它内部封装了需要关闭的资源（比如自定义的流包装器、连接池客户端等），那就可以让该类实现 AutoCloseable，再结合 try-with-resources 使用。
Builder 类本身不需改写，但可支持资源型实例
Builder 模式的职责是构造对象，不是管理生命周期。所以通常不需要修改 Builder 逻辑来适配 try-with-resources。真正要做的，是确保最终构建出的实例（比如 CarClient 或 DatabaseSession）实现了 AutoCloseable 接口，并在 close() 中释放其持有的资源。
- 例如，你有一个
FileReaderBuilder，它构建出的FileReaderWrapper内部持有BufferedReader，那么FileReaderWrapper应实现AutoCloseable - Builder 的
build()方法返回的就是这个可关闭对象，后续可直接用于 try-with-resources - 不需要在 Builder 内部做任何 close 相关操作，也不用让 Builder 实现 AutoCloseable
典型配合写法：先 build，再用 try-with-resources 包裹
这是最清晰、最符合职责分离的方式。Builder 负责“造出来”，try-with-resources 负责“用完即关”。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 代码示例：
try (DatabaseSession session = new DatabaseSession.Builder()
.host("localhost")
.port(3306)
.database("test")
.build()) {
session.execute("SELECT * FROM users");
} // 自动调用 session.close() - 前提是
DatabaseSession实现了AutoCloseable，且close()方法释放连接、关闭语句等 - Builder 只管设参数、校验、组装，不干预资源关闭时机
避免常见误区
有些开发者试图在 Builder 中提前声明资源、甚至在 build 前就打开流，这会破坏 Builder 的无状态性与可复用性，也违背 try-with-resources 的设计初衷。
立即学习“Java免费学习笔记（深入）”；
- ❌ 不要在 Builder 构造过程中打开文件或连接（比如在
build()里 new FileInputStream） - ❌ 不要让 Builder 实现
AutoCloseable—— Builder 是工厂，不是资源 - ❌ 不要将 try-with-resources 写在 Builder 链式调用内部（如
new Builder().open().doSomething().close()），这等于手动管理，失去语法优势 - ✅ 正确姿势：Builder → 得到一个
AutoCloseable实例 → 交给 try-with-resources 管理
进阶：Builder 可预置资源关闭策略（非必须，但更灵活）
如果业务需要多种关闭行为（如“只关闭连接” vs “关闭连接并清空缓存”），可在 Builder 中添加配置项，影响最终对象的 close() 行为。
- 例如：
builder.withCleanupOnClose(true)，构建出的实例在close()时额外执行清理逻辑 - 这种设计保持了 Builder 的表达力，又不侵入资源管理主流程
- 仍由 try-with-resources 触发
close()，只是具体行为可配置
