ETL中防SQL注入必须用参数化查询；PySpark的spark.sql()不支持参数化，拼接字符串必然导致注入，应改用filter或jdbc predicates。
批处理ETL任务中，只要外部数据（如上游字段、配置参数、CLI传参、API响应）参与SQL构建，且未走预编译路径，就存在SQL注入风险——这不是“可能”，而是“必然”会触发，尤其当数据含 '、;、-- 或 OR 1=1 类片段时。
PySpark中spark.sql()为什么不能直接拼接字符串？
spark.sql() 底层调用的是 HiveQL 解析器，不支持 JDBC 那类参数化机制；它接收纯 SQL 字符串，一旦你写 f"SELECT * FROM t WHERE name = '{user_input}'"，恶意输入就会被当作语法一部分执行。
- 错误示例：
spark.sql(f"SELECT * FROM users WHERE country = '{country_arg}'")—— 输入CN' OR '1'='1直接绕过条件 - 正确替代：改用
df.filter("country == ?").withColumn(...)或spark.read.jdbc(..., predicates=["country = ?"], ...)，让 Spark 在 JDBC 层走PreparedStatement - 注意：
predicates参数只支持简单等值或范围条件（如"id > ? AND id ），不支持 <code>IN列表或动态列名
Talend里tMysqlInput的PreparedStatement开关没生效？
勾选了「Use PreparedStatement」却仍被注入，大概率是组件配置没配对：Talend 的占位符解析和 JDBC 预编译是两道关卡，漏一关就失效。
- 必须同时满足：① 勾选开关；② SQL 编辑框中只用
?占位（禁用${row1.name}、#{context.country}等表达式）；③ 「Parameters」表格中为每个?明确指定 Type（如 MySQL 的INT字段不能设成VARCHAR，否则隐式转换可能绕过校验） - 常见陷阱：在 SQL 中写
WHERE status IN (${status_list})——${}是 Talend 表达式引擎拼串，发生在 JDBC 执行前，完全绕过 PreparedStatement - 安全做法：若需
IN动态列表，先用tJavaRow或tMap把输入转成固定长度数组，再通过多行参数传入（如status IN (?, ?, ?)）
dbt模型里{{ var('env') }}算参数化吗？
不算。{{ var('env') }} 是 Jinja 模板渲染，发生在 SQL 生成阶段，输出结果直接喂给下游引擎（如 Spark 或 Postgres）。它和字符串拼接没有本质区别。
- 高危写法：
WHERE env = '{{ var("env") }}'—— 若 CLI 调用时传--vars '{"env": "prod' OR '1'='1"}'，生成的 SQL 就是WHERE env = 'prod' OR '1'='1' - 安全写法：① 白名单硬编码校验：
{% if var('env') in ['dev', 'staging', 'prod'] %}WHERE env = '{{ var("env") }}'{% endif %}；② 改用IN宏：WHERE country IN {{ ['CN', 'US'] | inclause }}；③ 关键过滤逻辑下沉到上游已清洗表（如ref('stg_countries')） - 注意：
inclause宏仅对字面量数组安全；若数组来自{{ var('country_list') | inclause }}，仍需先校验var('country_list')是否为合法列表
NiFi中ExecuteSQL处理器启用ParameterizedSQL后还踩什么坑？
启用 Use Parameterized SQL 只解决值条件（WHERE / HAVING）的安全问题，但表名、列名、ORDER BY 子句无法参数化——这些地方若依赖外部输入，必须用白名单或拒绝动态化。
- 允许：
SELECT name, email FROM users WHERE status = ? AND created_at > ?+ 参数列表填${flowfile.attr.status}和${now()} - 禁止：
SELECT * FROM ${flowfile.attr.table_name}—— 必须硬编码表名，或从预设映射表查出（如table_map.get(${flowfile.attr.source}, 'default_table')） - 更隐蔽的风险：
ORDER BY ${sort_column} ${sort_order}—— 即使加了单引号包裹，sort_column若为id; DROP TABLE users--，仍可能在某些数据库驱动中触发多语句执行
真正难防的不是 ? 占位写错，而是那些“不得不动态”的地方：表名、列名、聚合函数名、窗口定义。这些位置没有标准参数化路径，只能靠白名单、静态映射或彻底重构流程来隔离风险——一旦放开，就是把 SQL 解析器的控制权交给了上游数据。
