跨数据库防注入需将参数化查询机制下沉至抽象层，因表名列名等结构部分不支持占位符，必须白名单校验；QuerySpec 结构解耦意图与适配，ORM 安全边界限于标准 API，类型与分页语法差异须由执行器统一处理。
跨数据库开发时，无法靠“一套SQL通吃所有库”，但防注入这件事必须统一解决——核心是把参数化查询的机制下沉到抽象层，而不是在每个方言里重复写 PreparedStatement 或 execute_query。
为什么不能直接拼接表名或列名？
参数化查询只对**值（value）** 有效，对表名、列名、排序字段、LIMIT 数字等结构部分完全无效。一旦你写 SELECT * FROM ? 或 ORDER BY ?，几乎所有数据库驱动都会报错，比如 PostgreSQL 抛 ERROR: syntax error at or near "$1"，MySQL 返回 You have an error in your SQL syntax。
- 这类结构部分必须走白名单校验或预定义映射，不能依赖用户输入动态生成
- 常见踩坑：用
${table}拼接 MyBatis 的<script></script>，或用f"SELECT * FROM {user_table}"在 Python 中构造语句 - 即使加了
re.match(r'^[a-zA-Z_][a-zA-Z0-9_]*$', table_name)，也挡不住 Unicode 标识符绕过（如含下划线变体字符）
如何设计可跨库的参数化抽象层？
关键不是“写一个通用SQL字符串”，而是把“查询意图”和“数据库适配”解耦。例如定义一个结构体：
class QuerySpec:
table: str # 必须来自白名单
columns: list[str] # 如 ["id", "name"]
where: dict # {"status": "=", "active": True}
order_by: str # 必须是预设字段之一，如 "created_at"
limit: int | None # 类型强制为 int，避免传入字符串- 所有字段名、表名由配置或枚举控制，不接受自由文本输入
-
where字段用键值对表达条件，后端按目标库语法翻译成WHERE status = ?或WHERE status = %s - PostgreSQL 需要
$1占位符，SQLite 用?，MySQL 用%s—— 这些差异应由执行器封装，上层代码无感知
ORM 或 Query Builder 能否替代手写抽象？
可以，但要注意它们的“安全边界”在哪。Django ORM 默认防注入，但 extra()、raw()、annotate() 中嵌入的字符串仍可能触发漏洞；SQLAlchemy 的 text() 同样危险。
- 安全用法：全部走
filter(status=...)、order_by(User.name)、limit(10) - 危险用法：
filter(text("status = '{}'".format(user_input)))、order_by(text(user_supplied_field)) - 若必须动态列名，优先用
getattr(User, user_col)取属性对象，而非拼字符串
最易被忽略的兼容性陷阱
不同数据库对 NULL 处理、字符串截断、自动类型转换规则不一致，这会让同一套参数化逻辑在 MySQL 上跑通，在 PostgreSQL 上因隐式类型不匹配而报错，进而诱使开发者退回到字符串拼接。
- 例如
WHERE created_at > ?，传入"2024-01-01"字符串：MySQL 宽容转为日期，PostgreSQL 直接报operator does not exist: timestamp without time zone > text - 解决方案：统一用
datetime对象传参，或在抽象层做类型归一（如把所有时间字段转为 ISO 格式 + 显式类型标注） - 另一个坑是 LIMIT/OFFSET：SQL Server 用
OFFSET 10 ROWS FETCH NEXT 5 ROWS ONLY，而 SQLite 用LIMIT 5 OFFSET 10—— 必须由执行器翻译，不能指望用户写“通用SQL”
