SQL参数化查询是防止SQL注入最有效、最基础的手段，核心在于让数据与SQL逻辑彻底分离：用户输入永远作为“值”传入，绝不会被数据库当作SQL代码执行；需严格区分拼接与参数化，所有动态值必须参数化，表名列名等非值内容须用白名单校验，并配合最小权限、输入校验、错误脱敏等多重防御。
SQL参数化查询是防止SQL注入最有效、最基础的手段，核心在于让数据与SQL逻辑彻底分离：用户输入永远作为“值”传入，绝不会被数据库当作SQL代码执行。
明确区分“拼接”和“参数化”
错误做法（字符串拼接）：
危险！直接拼接用户输入，极易被注入
string sql = "SELECT * FROM users WHERE username = '" + username + "'";
正确做法（使用参数占位符）：
数据库驱动自动处理类型、转义和上下文隔离
- SQL Server（C#）：
cmd.Parameters.AddWithValue("@name", username); - MySQL（Python/PyMySQL）：
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)) - PostgreSQL（Node.js/pg）：
client.query('SELECT * FROM logs WHERE level = $1', ['error'])
所有动态值都必须参数化，不放过任何例外
常见误区：只对WHERE条件参数化，忽略ORDER BY字段、LIMIT数量、表名或列名——这些不能参数化，需用白名单校验
- ✅ 允许参数化的：WHERE值、INSERT值、UPDATE SET值、IN列表中的每个元素（用对应数量占位符）
- ❌ 不允许参数化的：表名、列名、排序方向（ASC/DESC）、分页偏移量（需整型强转+范围检查）
- ? 替代方案：用预定义白名单映射用户输入，例如：
sortCol = {"name": "user_name", "time": "created_at"}.get(userSort, "id")
使用预编译语句（Prepared Statement）并复用
多数数据库驱动在首次执行带参数的SQL时会自动预编译，后续执行仅传参，既提升性能又增强安全性
- 避免每次查询都新建SQL字符串，尤其在循环中
- ORM如Entity Framework、Django ORM、MyBatis默认启用参数化，但需确认未开启“原始SQL拼接”开关
- 警惕ORM中的
raw()、execute()、$sql等绕过机制——它们仍需手动参数化
配合其他防御层，不依赖单一手段
参数化是基石，但不是万能解药。需叠加最小权限、输入校验、错误信息脱敏等措施
- 数据库账号仅授予必要权限（如不用root连接应用）
- 前端+后端双重校验输入格式（如手机号正则、ID长度限制），虽不防注入但可快速拦截异常请求
- 生产环境关闭详细SQL错误提示，避免暴露表结构或数据库版本
