强类型参数绑定通过在数据库驱动层物理隔离sql结构与用户数据，使sql注入在语法层面不可能成立；它比mysqli_real_escape_string()更可靠，因后者仅作文本替换且易受字符集或上下文影响而失效。

强类型参数绑定不是“加一层防护”，而是把 SQL 语句结构和用户数据在数据库驱动层就物理隔离。只要绑定过程没绕过，SQL 注入在语法层面就不可能成立。

为什么 bind_param("s", $user_input) 比 mysqli_real_escape_string() 更可靠

前者让数据库引擎明确知道：这个值只能是字符串，且只参与数据填充；后者只是对引号、反斜杠做文本替换，一旦字符集不一致（比如 GBK 双字节截断）、或出现在非引号上下文（如 ORDER BY 后），就会失效。

• mysqli_real_escape_string() 依赖连接字符集设置，SET NAMES gbk 下可能被绕过
• bind_param() 的类型标记（"s"/"i"/"d"）由 MySQLi 扩展强制传给服务器，不经过字符串拼接环节
• 数字型参数用 "i" 绑定后，哪怕传入 "1 OR 1=1"，也会被转成整数 1，后面部分直接丢弃

PDO::prepare() 中 :name 和 ? 占位符的实际差异

两者都安全，但语义和维护成本不同：? 是位置占位，靠顺序匹配；:name 是命名占位，靠键名匹配。实际执行时无性能差别，但出错时调试体验差很多。

• 用 ? 时，如果 bindValue(1, $a) 写成 bindValue(2, $a)，会报 Invalid parameter number，但错误位置难定位
• 用 :email 时，bindValue(":email", $_POST['email']) 错写成 bindValue(":mail", ...)，PDO 直接忽略该绑定，查不到数据但不报错——容易漏掉逻辑缺陷
• 批量插入场景下，?:name, ?:age 比重复写 ?, ? 更易读，尤其字段超过 5 个时

MyBatis 的 #{} 和 ${} 本质区别不是“转义与否”，而是执行阶段

#{} 在预编译阶段生成 PreparedStatement 占位符；${} 是纯字符串替换，在 SQL 拼装阶段就完成了——它根本没进数据库预编译流程。

• ORDER BY ${column} 看似方便，但 column = "id; DROP TABLE users--" 会直接拼进 SQL 字符串
• 真要动态列名或表名，必须白名单校验：if (!in_array($column, ['id', 'name', 'created_at'])) die('invalid column')
• #{} 对空值默认转成 NULL，而 ${} 为空时可能拼出 WHERE status = 导致语法错误

Rust 的 sqlx::query!() 宏为什么能提前拦住问题

它不是运行时检查，而是在 cargo build 阶段就连接数据库、解析 SQL 结构并校验参数类型与表结构是否匹配。表字段删了、类型变了、甚至列名拼错，编译直接失败。

• 普通 sqlx::query() 只做运行时绑定，错误要到请求时才暴露
• query!() 要求编译环境能连上开发库，CI 流程中需配置 TEST_DATABASE_URL
• 不支持复杂表达式，比如 WHERE created_at > NOW() - INTERVAL ? DAY 中的 ? 会被拒绝，得改用 query_as!() 或拆成两步

真正容易被忽略的是：强类型绑定只保“参数值”，不保“参数上下文”。比如把用户输入塞进 ORDER BY、GROUP BY、LIMIT 或表名位置，再严格的绑定也无效——这些地方必须走白名单或枚举校验，没有捷径。