SQL 注入大家并不陌生。是一种常见的攻击方式。攻击者在界面的表单信息或url上输入一些奇怪的SQL片段java 防sql注入代码，如“or '1'='1'”。参数验证不足可能会入侵应用程序。所以我们需要在我们的应用程序中做一些工作来防止这种攻击。在一些安全性较高的应用程序中，例如银行软件，经常采用将所有SQL语句替换为存储过程的方法来防止SQL注入。这当然是一种非常安全的方法，但是在我们平时的开发中，可能不需要这种死板的方法。
作为半自动持久层框架，sql语句必须自己手动编写。当然，此时我们需要防止sql注入。其实sql就是一个带有“输入+输出”功能的结构体，功能类似，如下：
=”int”>
id,title,,
来自 id=#{id} 的博客
这里表示输入参数类型，表示输出参数类型。针对以上情况，如果我们要防止sql注入，那么在输入参数上下功夫是理所当然的。上面代码中高亮部分是sql中拼接输入参数的部分。传入参数后，打印出执行的sql语句，你会看到sql是这样的：
id,title,, from blog where id = ?
不管输入什么参数，打印出来的sql都是这样的。这是因为启用了预编译功能。在执行 SQL 之前，会将上述 SQL 发送到数据库进行编译。执行时直接使用编译好的SQL，占位符“？”可以更换。因为SQL注入只能作用于编译过程，所以这种方法可以避免SQL注入的问题。
如何进行sql预编译？事实上，在框架的最底层，jdbc中的类在起作用，这是我们非常熟悉的一个子类。它的对象包含已编译的 SQL 语句。这种“ready”的方式不仅可以提高安全性，还可以在多次执行一条sql时提高效率如何做到sql预编译的呢？(一)注入？，因为该sql已经编译完成，再次执行时不需要再次编译。
说起来，我们可以通过使用它来防止sql注入吗？当然不是，看下面的代码：
=“地图”>
id,title,,
来自博客订单，按 ${}
仔细观察，内联参数的格式已从“#{xxx}”更改为 ${xxx}。如果我们将参数“”赋值给“id”并打印sql，它看起来是这样的：
id,title,,from
博客按 id 排序
显然，这并不能阻止sql注入。其中，“${xxx}”格式的参数会直接参与sql编译，因此无法避免注入攻击。但是，当涉及到动态表名和列名时，只能使用“${xxx}”的参数格式。因此，此类参数需要在代码中手动处理java 防sql注入代码，防止注入。
在编写映射语句时，尽量使用“#{xxx}”格式。如果必须使用“${xxx}”等参数，则必须手动进行过滤以防止SQL注入攻击。