str模板处理器不适合拼装sql，因其不防sql注入、无参数绑定与类型检查、属不稳定的预览特性；仅限完全可控的静态内容组装，生产环境应使用preparedstatement或orm。
JDK 21 的 String Templates（通过 STR 处理器）**不能直接用于生产环境的 SQL 拼装或 HTML 输出**——它目前仍是预览特性，且缺乏注入防护、转义机制和运行时校验能力。强行用它替代参数化查询或模板引擎，会引入严重安全风险。
为什么 STR 模板不适合拼装 SQL
SQL 拼接最核心的约束是：必须防止 SQL 注入。而 STR 模板对表达式值不做任何处理，原样插入：
- 若
username = "admin' -- "，STR."SELECT * FROM users WHERE name = '\{username}'"会生成可执行的恶意语句 -
STR不提供类似PreparedStatement的占位符绑定、类型检查或驱动层预编译能力 - 预览 API 可能在 JDK 22+ 被修改甚至移除，SQL 层逻辑一旦耦合，后续升级成本极高
哪些场景下可以谨慎尝试 STR + 文本块
仅限**完全可控、无用户输入、非执行用途**的静态内容组装，比如生成调试日志、内部配置片段或测试用例中的预期 SQL 字符串：
- 多行 SQL 片段拼接（仅用于单元测试断言）：
String expected = STR.""" SELECT id, name FROM users WHERE status = \{Status.ACTIVE} AND created_at > '\{Instant.now().minusDays(7)}' """; - HTML 静态骨架（如邮件模板初稿、文档示例）：
String html = STR.""" <div class="card"> <h3>\{title}</h3> <p>Generated at \{LocalDateTime.now()}</p> </div> """; - 关键前提：所有内嵌表达式都来自枚举、常量、硬编码或已清洗过的可信上下文
真正该用什么替代传统字符串拼接
不是用 STR，而是升级工具链本身：
- SQL 场景 → 统一走
PreparedStatement或 ORM（如 MyBatis 的<script></script>+ 绑定变量，或 JPA 的@Query+#{}） - HTML/JSON/XML 输出 → 用专业模板引擎（Thymeleaf、Freemarker、Jackson
ObjectMapper）而非手拼 - 若坚持纯 Java 字符串组合 →
String.formatted()+ 文本块（JDK 15+ 稳定 API），比STR更可靠：String sql = """ SELECT * FROM orders WHERE user_id = %s AND status = %s """.formatted(userId, status.name());
真正容易被忽略的点是：开发者常把“语法更短”等同于“更安全”或“更合适”。但 SQL 和 HTML 的本质是结构化协议，不是普通字符串——它们需要语义解析、上下文隔离和防御性输出，这些 STR 一个都不提供。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
