防止sql注入最有效的方式是使用参数化查询，通过预编译语句实现数据与代码分离，确保用户输入仅作为数据绑定而非sql指令执行。

防止SQL注入最有效的方式是使用参数化查询，而不是拼接SQL字符串。核心原则是：数据与代码分离，让数据库明确区分“要执行的指令”和“要处理的数据”。

参数化查询：用占位符代替字符串拼接

参数化查询通过预编译语句（Prepared Statement）实现，数据库先解析SQL结构，再安全地绑定用户输入值。不同语言写法略有差异，但逻辑一致：

• Python（sqlite3 / psycopg2）：用?（SQLite）或%s（PostgreSQL）作占位符，传参时单独提供值列表或字典，不参与SQL拼接
• Java（JDBC）：使用PreparedStatement，调用setString()、setInt()等方法赋值
• C#（ADO.NET）：用@paramName命名参数，配合SqlParameter对象传入
• PHP（PDO）：用?或:name占位，调用execute()传数组，避免mysql_query()等已废弃且无参数支持的函数

避免常见误操作

即使用了参数化，以下做法仍可能引入风险：

• 动态拼接表名、列名、排序字段（如ORDER BY $_GET['sort']）——这些无法参数化，需白名单校验
• 在SQL中用字符串拼接构造条件（如"WHERE status = '" + input + "'"），哪怕其他部分用了参数
• 把参数值先做addslashes()或mysql_real_escape_string()再拼接——这是过时且不可靠的防御方式
• 使用exec()、eval()或存储过程中拼接SQL（如T-SQL的EXEC(@sql)）——必须用sp_executesql配合参数

辅助防护措施

参数化是第一道防线，还需叠加其他实践提升整体安全性：

• 最小权限原则：应用数据库账号仅授予必要权限（如只读表不用DROP或GRANT）
• 输入验证：对格式敏感字段（邮箱、手机号、日期）做正则或类型校验，但不能替代参数化
• 错误信息脱敏：关闭数据库详细错误提示（如show_sql_errors = off），避免泄露表结构
• 使用ORM时确认其底层是否真正参数化（如Django ORM默认安全，但extra()或raw()需谨慎）

不推荐的“伪安全”做法

有些方式看似过滤，实则容易绕过或破坏逻辑：

• 仅过滤单引号（'）、分号（;）、注释符（--、/*）——Unicode编码、宽字节注入、大小写混用可绕过
• 用htmlspecialchars()处理输入后存入数据库——这是针对XSS的，对SQL注入无效
• 前端JavaScript校验——完全可被绕过，服务端必须独立校验
• 依赖WAF规则拦截SQL关键字——规则滞后、易误杀、无法覆盖所有变种