preparedstatement不能给表名加问号，因sql解析器预编译阶段需校验表名存在性与权限，而?仅支持值（value）不支持标识符（identifier），表名属语法结构，必须在参数绑定前确定。
PreparedStatement 为什么不能给表名加问号
因为 SQL 解析器在预编译阶段就必须确认表名是否真实存在、是否有访问权限——这属于语法结构校验，发生在参数绑定之前。数据库不允许把表名、列名、排序方向（ASC/DESC）、GROUP BY 字段这些“结构元素”用 ? 占位，否则会直接报错，比如：
SELECT * FROM ? WHERE id = ?
MySQL 会返回错误：ERROR 1064 (42000): You have an error in your SQL syntax。
根本原因不是 JDBC 驱动限制，而是 SQL 标准和数据库引擎设计决定的：预编译只支持值（value），不支持标识符（identifier）。占位符只能出现在表达式右侧、WHERE 条件值、IN 列表项等数据位置，不能出现在对象名上下文。
动态表名常见错误写法与风险
很多人以为“用了 PreparedStatement 就安全了”，结果写出这种代码：
String sql = "SELECT * FROM " + userInputTable + " WHERE id = ?";PreparedStatement ps = conn.prepareStatement(sql);ps.setLong(1, id);
这段代码里，userInputTable 是用户可控的，哪怕后续参数走 setLong()，也完全无效——因为表名已经拼进 SQL 字符串，提前送进解析器了。
常见攻击方式包括：
- 输入
users; DROP TABLE config--触发多语句执行（如果驱动开启allowMultiQueries=true） - 输入
users UNION SELECT password FROM admin篡改查询意图 - 输入
information_schema.tables探测数据库结构
安全替代方案：白名单校验必须做严
动态表名没有“参数化”这条路，只能靠服务端强约束：
- 用正则硬过滤：只允许小写字母、数字、下划线，且长度限制在 64 字节内
input.matches("^[a-z][a-z0-9_]{1,63}$") - 更推荐枚举白名单：把合法表名写死在
Set.of("order_2026", "order_2025", "user_profile")里，查不到就拒绝 - 如果表名来自配置中心或元数据（如
SHOW TABLES LIKE 'log_%'），需额外校验该表是否归属当前租户/业务域 - 绝对不要依赖前端传来的“表名前缀”做字符串拼接，比如
"log<em>" + year</em>—— year 若未校验范围，可能拼出log-1或log_; TRUNCATE users
MyBatis 里 ${} 和 #{} 混用时的陷阱
MyBatis 的 ${} 是纯字符串替换，和 PreparedStatement 完全无关：
<select id="query" resulttype="map"></select> SELECT * FROM ${tableName} WHERE status = #{status}
这里 #{status} 安全，但 ${tableName} 不安全。即使你对 tableName 做了 setString() 绑定也没用——它压根没进 PreparedStatement 流程。
容易被忽略的一点是：框架不会自动帮你校验 ${} 插入的内容是否合规。一旦漏掉白名单逻辑，又恰好暴露了分表路由、报表字段等接口，就等于在防护墙上凿了个洞。
