preparedstatement本身不会自动展开参数生成完整sql，调试时推荐用p6spy等代理日志工具；其次可手写拼接（仅限调试）；部分jdbc驱动支持profilesql等调试开关；不建议反射或重写类获取参数。
Java 中 PreparedStatement 本身**不会自动展开参数值生成完整 SQL 字符串**，这是出于安全（防 SQL 注入）和实现机制（参数由数据库驱动在底层绑定）的考虑。但开发调试时，我们常需要“看到”最终执行的 SQL。以下是几种实用、可靠的方法：
方法一：使用日志框架 + JDBC 代理（推荐）
通过代理数据源（如 log4jdbc-log4j2 或 P6Spy）拦截并打印带参数的真实 SQL，最接近生产环境行为，且不侵入业务代码。
- 以 P6Spy 为例：引入依赖后配置
p6spy.properties，将原 JDBC URL 替换为jdbc:p6spy:mysql://... - 它会自动把
SELECT * FROM user WHERE id = ?+[123]日志为SELECT * FROM user WHERE id = 123 - 支持格式化、慢 SQL 记录、执行时间统计，适合测试和预发环境
方法二：手写 SQL 拼接（仅限调试，禁止用于生产）
适用于单元测试或临时调试，需手动替换 ? 占位符，注意类型处理（字符串加引号、null 转 NULL）：
<font color="#888">String sql = "SELECT * FROM orders WHERE status = ? AND amount > ? AND created_at >= ?";</font><br><font color="#888">PreparedStatement ps = conn.prepareStatement(sql);</font><br><font color="#888">ps.setString(1, "PAID");</font><br><font color="#888">ps.setBigDecimal(2, new BigDecimal("100.00"));</font><br><font color="#888">ps.setTimestamp(3, Timestamp.valueOf("2024-01-01 00:00:00"));</font><br><br><font color="#888">// 手动构建可读 SQL（仅调试用）</font><br><font color="#888">String debugSql = sql;</font><br><font color="#888">debugSql = debugSql.replaceFirst("\?", "'PAID'");</font><br><font color="#888">debugSql = debugSql.replaceFirst("\?", "100.00");</font><br><font color="#888">debugSql = debugSql.replaceFirst("\?", "'2024-01-01 00:00:00'");</font><br><font color="#888">System.out.println(debugSql); // SELECT * FROM orders WHERE status = 'PAID' AND amount > 100.00 AND created_at >= '2024-01-01 00:00:00'</font>
注意：此方式易出错（如未转义单引号、时区/格式差异），且无法处理 BLOB/CLOB 等类型，切勿用于日志输出到生产系统。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
方法三：利用数据库驱动的调试能力（部分支持）
某些 JDBC 驱动提供内部调试开关，例如：
-
MySQL Connector/J：启用
logger=com.mysql.cj.log.StandardLogger和profileSQL=true，会在日志中打印带参数的 SQL -
HikariCP + logback：设置
logger.com.zaxxer.hikari=DEBUG可看到 prepare 和 execute 过程，结合驱动日志可推断实际语句
效果依赖驱动版本和配置粒度，不如 P6Spy 稳定直观。
为什么不建议重写 PreparedStatement 或反射取参数？
虽然可通过反射访问 PreparedStatement 内部参数数组（如 MySQL 的 parameterValues），但：
- 不同驱动实现私有字段名不同（Oracle、PostgreSQL、SQL Server 各不相同）
- 字段可能被封装或移除（新版本兼容性差）
- 无法还原类型转换逻辑（如
setDate→yyyy-MM-dd格式） - 违反封装原则，增加维护风险
这类“黑盒操作”应避免。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
