Diesel DSL天然防SQL注入，因其在编译期锁死SQL结构，用户输入仅作绑定值；sql_query绕过校验，需严格使用参数化且配合白名单校验。
diesel 的 DSL 查询在编译期就锁死 SQL 结构，用户输入只作为绑定值传入预编译语句，不参与字符串拼接——这才是它“天然防注入”的本质。
DSL 方法如 filter、eq 为什么不会中招
不是因为 Diesel “做了什么”，而是 Rust 类型系统 + schema.rs + Queryable 推导三者协同，让恶意拼接根本过不了编译：
-
users::name是从schema.rs生成的常量，类型为diesel::sql_types::Text；传入非兼容类型（比如i32）直接编译失败 -
users::table.filter(users::name.eq(name))中的name是纯值，全程不转成字符串、不进 SQL 文本 - 如果数据库表里根本没有
name字段，schema.rs就不会生成users::name，代码连use都写不下去 -
load::<user>()</user>时，编译器会比对 SELECT 列与User字段：少一个、多一个、类型错一个，全报错
sql_query 为什么是唯一可能翻车的入口
sql_query 绕过所有类型校验层，只做参数绑定，不检查字段名、类型、数量——它本就不是为日常 CRUD 设计的：
-
sql_query("SELECT * FROM users WHERE name = $1").bind(name)安全，但仅限 PostgreSQL；MySQL/SQLite 必须用?，且占位符顺序必须严格对应 -
sql_query(format!("... '{}'", name))或"..." + name—— 拼接发生在运行时，bind()完全无效 -
sql_query("SELECT id, name FROM users")返回SqlQuery，无法直接load<user>()</user>；字段名变更后，编译器不报错，运行时才 panic - 真要用，必须配
#[derive(QueryableByName)]+ 显式field_names+sql_type注解，漏一项就编译不过
动态字段名或表名怎么处理才安全
DSL 不接受变量作为字段名或表名——这不是限制，是保护。一旦你试图把字符串塞进 filter 或 select，编译器就会拦住你：
- 模糊搜索别写
sql_query(format!("%{}%", kw))，改用users::name.like(format!("%{}%", kw)) - 多条件查询别拼
WHERE字符串，用.filter()链式累积：let mut q = users::table.into_boxed(); if let Some(n) = name { q = q.filter(users::name.eq(n)); } - CLI 参数或管理命令里用
sql_query？先过白名单正则：Regex::new(r"^[a-zA-Z0-9_]+$")，否则拒绝执行 -
schema.rs本身不等于绝对可信——CI 流水线若被污染，生成的字段名也可能带恶意内容，迁移没跑，schema.rs就已失效
真正难防的从来不是语法错误，而是人对“这点小改动没问题”的判断。Diesel 给你的是铁轨，不是自动驾驶。
