diesel 本身不自动防 sql 注入，安全依赖类型系统和查询构建器约束；仅 sql_query 配合占位符与 bind() 安全，dsl 方法如 filter、insert_into 天然免疫；误拼接字符串或动态拼 sql 是主要风险点。
Diesel 本身不自动防 SQL 注入，但只要你不用 sql_query 手写原始 SQL 并拼接参数，就基本不会中招。 它的安全性来自类型系统和查询构建器的强制约束，不是魔法——用错方式照样翻车。
为什么 diesel::sql_query + .bind() 仍可能不安全
很多人以为只要用了 .bind() 就万事大吉，其实不然。问题出在字符串拼接上：
-
sql_query("SELECT * FROM users WHERE name = '" + name + "'")—— 即使后面调.bind()也无效，因为拼接已发生在 SQL 字符串里 -
sql_query(format!("SELECT * FROM users WHERE name = '{}'", name))—— 同样危险，format!在运行时执行，绕过所有 Diesel 的参数化机制 - 只有
sql_query("SELECT * FROM users WHERE name = $1").bind(name)这种才真正安全，且仅限 PostgreSQL；MySQL/SQLite 需用?占位符，且必须严格一一对应
select/insert_into 等 DSL 方法天然免疫注入
Diesel 的核心安全机制就藏在它的 DSL 里：所有查询由 Rust 类型推导生成，SQL 结构在编译期固定，用户输入只作为绑定值传入预编译语句。
-
users::table.filter(users::name.eq(name)).first::<user>(&conn)?</user>——name是纯值，不会进入 SQL 文本 -
insert_into(users::table).values(&new_user).execute(&conn)?——new_user被序列化为参数列表，非字符串插值 - 哪怕字段名、表名来自变量（比如动态筛选），也不能直接塞进 DSL；必须用
sql_query+ 显式白名单校验，否则 DSL 不接受
哪些场景容易误踩坑？
真实项目里最常翻车的不是新手，而是有经验者在“灵活需求”下放松警惕：
- 实现模糊搜索时写成
sql_query(format!("... LIKE '%{}%'", keyword))—— 正确做法是用users::name.like(format!("%{}%", keyword)) - 多条件动态查询时手动拼
WHERE子句字符串 —— 应该用.filter()链式累积，空条件直接跳过 - 迁移脚本或管理命令里调
sql_query处理用户输入（比如 CLI 参数）—— 必须先做正则白名单过滤，如Regex::new(r"^[a-zA-Z0-9_]+$") - 把
schema.rs里的字段名当信任源直接拼 SQL —— 字段名虽由 Diesel 生成，但若 schema 被恶意篡改（如 CI 流水线污染），仍有风险
真正难防的从来不是语法错误，而是人对“这点小改动没问题”的判断。Diesel 给你的是铁轨，不是自动驾驶——脱轨只在一念之间。
