SQL动态字段选择不能用参数化查询，因为?占位符仅支持值而非标识符（如字段名、表名），必须通过白名单校验后字符串拼接实现安全动态列。
SQL动态字段选择为什么不能直接用参数化查询
因为字段名不是数据值，PreparedStatement 的 ? 占位符只接受**值（value）**，不接受标识符（identifier），比如表名、列名、排序字段。强行塞进去会报 SQLSyntaxErrorException 或直接拼成非法语句。
常见错误现象：写成 SELECT ? FROM users WHERE id = ?，结果查出来字段名是字符串“name”，而不是 name 列的值。
- 只有
WHERE、ORDER BY后的值、IN列表里的元素能用? - 字段名、表名、函数名、
GROUP BY表达式、LIMIT数字（部分驱动支持，但不通用）都得走字符串拼接 - 拼接前必须白名单校验——这是唯一直接有效的防护手段
Java反射获取字段名的安全拼接方式
用反射读取实体类字段名本身不危险，但若把反射结果直接拼进 SQL，等于把攻击面交给了类定义——万一有人故意加个字段叫 id; DROP TABLE users--（虽然 Java 字段名语法不允许，但别依赖这个），或通过继承/代理注入恶意字段，风险就藏住了。
正确做法是：反射只作「字段存在性检查」+「白名单比对」，不参与拼接逻辑。
- 先定义允许查询的字段集合，比如
Set.of("id", "name", "email", "created_at") - 用反射拿到目标对象的
getDeclaredFields()，提取field.getName()，逐个判断是否在白名单中 - 只把通过校验的字段名用
String.join(", ", safeFields)拼进 SQL，不拼任何用户输入或注解值 - 避免用
@Column(name = "...")动态取值——注解内容不受编译期约束，可能被篡改
示例：
String sql = "SELECT " + String.join(", ", allowedFields) + " FROM users WHERE id = ?";
MyBatis动态SQL怎么避免字段注入
MyBatis 的 ${} 和 #{} 的混用边界。字段名必须用 ${}，但这就要求你确保传入的字段名变量是可信的。
-
${fieldName}是字符串替换，不做转义，所以fieldName必须来自白名单枚举或静态配置，绝不能来自 HTTP 参数或数据库字段 - 不要写
${fields} - 推荐用枚举限定字段组合：
public enum QueryField { ID, NAME, EMAIL }，然后在 DAO 层映射为固定字符串 - 如果真要支持任意字段组合，用
Map接收开关，再在 XML 里用
Python SQLAlchemy如何安全生成动态列查询
SQLAlchemy 的 select([table.c[col] for col in cols]) 看似安全，其实前提是 cols 是硬编码列表或经校验的字符串。一旦 cols = request.args.getlist('fields') 直接进循环，就等同于裸拼接。
- 永远不要用
getattr(table.c, col_name)处理不可信输入——它不校验，错名会抛AttributeError，但错名也可能被绕过（比如用__dict__注入） - 用
table.columns.keys()获取真实列名，再做集合交集：safe_cols = list(set(request_cols) & set(table.columns.keys())) - 注意大小写：PostgreSQL 默认小写，MySQL 默认不敏感，SQLite 取决于 OS——校验时统一转小写再比对
- 如果用了
hybrid_property或自定义 column 表达式，它们不在table.columns里，需单独维护白名单
字段名动态化的本质不是技术难题，是信任边界的划定问题。所有语言里，最易被忽略的一点是：**校验动作必须发生在 SQL 构造之前，且校验依据必须与数据库 schema 强一致，不能靠代码注释、文档或开发者的记忆来维护白名单**。
