必须同时满足宏调用、占位符语法、离线模式和schema快照四条件，缺一不可；sqlx::query!与query_as!本质区别在于编译期是否介入校验，非字面量sql拼接将导致校验失效或编译错误。
不能只靠写对函数名，必须同时满足宏调用、占位符语法、离线模式和 schema 快照四个条件，缺一不可。
sqlx::query! 和 sqlx::query_as! 的区别不是“要不要类型转换”，而是“编译期是否介入”
带 ! 后缀的才是宏，不带的只是普通函数。例如 sqlx::query_as（无感叹号）完全不解析 SQL 字符串，也不会校验字段是否存在、类型是否匹配；它只是在运行时把字符串发给数据库——和拼接 format! 一样危险。
常见误用：
-
sqlx::query_as("SELECT id FROM users WHERE name = $1").bind(name)→ ❌ 不校验表结构，不防注入 -
sqlx::query_as!("SELECT id FROM users WHERE name = $1", name)→ ✅ 编译期检查表、字段、参数类型，并强制绑定
注意：PostgreSQL 用 $1，SQLite 用 ?，MySQL 用 ?；混用会导致编译失败或运行时报错。
SQLX_OFFLINE=1 不是可选项，而是开启编译期检查的前提
如果不设这个环境变量，query! 宏会尝试在编译时连真实数据库——连不上就直接报错，但不是“检查失败”，而是“根本没机会检查”。更糟的是，有些 CI 环境里数据库可连通，却没权限查 information_schema，导致校验静默失效。
正确做法：
- 开发阶段：先确保本地 DB 可访问，运行
sqlx prepare --database-url 'sqlite://dev.db' - 提交生成的
.sqlx/目录到 Git - 构建时设置
SQLX_OFFLINE=1（Cargo.toml 中可通过[env]或 CI 脚本注入）
漏掉 .sqlx/ 或没设 SQLX_OFFLINE=1，所有 query! 都退化为普通字符串查询，等于裸奔。
字符串拼接仍是最大漏洞来源，哪怕只拼接表名或字段名
有人以为“只拼接表名，参数还是用 $1”就安全了，比如：
let table = "users";
sqlx::query_as!(User, &format!("SELECT * FROM {} WHERE id = $1", table), id)
这行不通：query_as! 宏只接受字面量字符串（literal string），不接受变量拼接结果。Rust 编译器会直接报错：argument must be a string literal。
真正能绕过检查的写法只有两种：
- 用
format!拼出完整 SQL，再传给sqlx::query（无感叹号）→ ❌ 注入高危 - 用
concat!或const字符串拼接，但依然受限于宏只认字面量 → 实际几乎不可行
结论：任何动态构造 SQL 的需求（如多租户切换表名），都不能依赖 query!，得换方案——比如白名单校验 + sqlx::query 运行时执行，或改用视图/预定义查询。
最容易被忽略的一点：宏的校验能力完全依赖 .sqlx/ 里的 schema 快照是否最新。如果数据库加了字段但没重新 sqlx prepare，编译通过，但运行时可能因字段缺失而 panic——这不是注入问题，却是类型安全承诺的断裂点。
