別：預編譯原理、SQL注入風險與動態(tài)SQL實戰(zhàn))
面試場景里有一個問題出現(xiàn)頻率很高而且很多候選人答不到點上MyBatis 里#{}和${}有什么區(qū)別為什么已經有了安全的#{}還要設計一個容易被SQL注入的${}如果只回答“#{}是預編譯${}是字符串拼接”面試官大概率還會追問那預編譯為什么能防注入字符串拼接為什么危險動態(tài)排序、動態(tài)表名的需求到底怎么處理這種追問能快速區(qū)分“背過八股文”和“真正在項目里寫過MyBatis”的人。這篇文章從JDBC預編譯機制講起用一個最小工程演示#{}和${}在同樣一條SQL上的差異再分析${}在動態(tài)SQL里的真實使用場景最后給出白名單校驗、日志配置、權限控制等工程建議。讀完你不僅知道怎么答還能知道項目中踩到類似問題怎么排查。1. 面試官問這個問題到底想考察什么先說結論這道題考察的不是“記沒記住兩個符號的區(qū)別”而是三件事。第一對SQL注入原理的理解。SQL注入為什么能發(fā)生因為用戶輸入被拼接成了SQL語法的一部分改變了語句原本的執(zhí)行語義。如果只是數(shù)據(jù)庫查詢結果變了那叫數(shù)據(jù)問題如果SQL結構被改變那才是安全問題。很多候選人能說出“SQL注入就是把惡意SQL拼進去”但說不清楚拼進去之后SQL引擎到底發(fā)生了什么。第二對JDBCPreparedStatement的理解。MyBatis的#{}最終會生成JDBC預編譯占位符?這是安全的基本前提。如果連預編譯、占位符、參數(shù)綁定這幾個概念都不熟說明底層功底不足。第三對框架設計取舍的理解。MyBatis不是不知道${}危險它依然保留這個能力因為SQL里有“值”和“結構”兩類內容。值可以參數(shù)化結構不能。這就是面試官想聽的“設計原因”而不是簡單一句“用來拼接的”。所以準備這道題時不要背答案要先建立一條完整鏈路用戶輸入 → MyBatis解析 → JDBC SQL構造 → 數(shù)據(jù)庫執(zhí)行。每一步都可能成為攻擊面也都有對應的防御手段。2. SQL注入的本質與 #{} 的安全原理先看一個經典的登錄場景。后端要校驗用戶名和密碼SQL寫成這樣SELECT * FROM sys_user WHERE username admin AND password 123456如果密碼是用戶輸入拼接出來的攻擊者輸入下面的字符串 OR 11 --拼接后SQL變成SELECT * FROM sys_user WHERE username admin AND password OR 11 --OR 11恒為真注釋符號--把后面的SQL注釋掉。這條語句在數(shù)據(jù)庫里執(zhí)行時實際生效的條件只剩WHERE 11等同于查詢全表。這就是SQL注入的最典型例子核心在于輸入內容進入了SQL語句的語法結構層而不是被當作一個普通參數(shù)值。JDBC里對應有兩種寫法。第一種是字符串拼接// 錯誤示例拼接SQL String sql SELECT * FROM sys_user WHERE username username AND password password ; Statement statement connection.createStatement(); ResultSet rs statement.executeQuery(sql);這種方式下用戶輸入直接嵌入SQL文本數(shù)據(jù)庫會把整個字符串當作可執(zhí)行SQL解析。第二種是預編譯// 安全示例預編譯 參數(shù)綁定 String sql SELECT * FROM sys_user WHERE username ? AND password ?; PreparedStatement ps connection.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs ps.executeQuery();?是占位符setString()把參數(shù)值交給數(shù)據(jù)庫驅動處理。數(shù)據(jù)庫先解析SQL結構再綁定參數(shù)。用戶輸入無論包含多少單引號、注釋符、關鍵字都只是某個占位符的值不會改變SQL結構。MyBatis的#{}本質上就是第二種方式。下面這兩條XML中的SQL效果相同select idselectUserByUsername resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE username #{username} AND status 1 /selectMyBatis會把#{username}替換成?然后在執(zhí)行時通過PreparedStatement綁定實參。攻擊者輸入 OR 11 --最終傳遞到數(shù)據(jù)庫的SQL是SELECT id, username, password, status FROM sys_user WHERE username ? AND status 1綁定參數(shù)后username的值就是那一長串字符它只會跟username字段做等值比較不會變成OR條件。有一點需要補充預編譯防注入的前提是SQL語句結構在預編譯階段已經固定。如果SQL本身存在動態(tài)拼接比如后面的${}那結構就是變化的預編譯機制也無法保護不可信的結構部分。#{}和${}的差異可以匯總成下表對比項#{}${}實現(xiàn)方式預編譯占位符?字符串直接替換SQL注入風險低參數(shù)不會進入SQL語法層高輸入可能改變SQL結構適用場景條件值、查詢參數(shù)、插入值表名、排序字段、列名等結構部分使用方式#{param}${param}性能相同SQL可復用預編譯語句每次拼接新SQL緩存收益有限調試可讀性日志中顯示占位符日志中顯示完整SQL3. 環(huán)境準備與最小工程搭建為了直觀驗證#{}和${}的差異我們搭建一個Spring Boot MyBatis的最小演示工程。在進行任何SQL注入驗證時務必使用本地測試數(shù)據(jù)庫不要在生產環(huán)境或未授權系統(tǒng)上操作。假設你本機已有JDK和MySQL環(huán)境。JDK版本、Spring Boot版本、MySQL版本以你本機實際環(huán)境為準本文重點是演示通用思路不需要強綁定某個版本。首先創(chuàng)建一個Spring Boot項目引入MyBatis依賴。在pom.xml中加入dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version請?zhí)鎿Q為項目實際可用版本/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency如果你的項目是基于Spring Boot 3.xMyBatis官方推薦使用mybatis-spring-boot-starter的最新版本如果是Spring Boot 2.x使用對應兼容的舊版本。版本差異不影響本文核心結論。接著在src/main/resources/application.yml中配置數(shù)據(jù)源和MyBatis日志spring: datasource: url: jdbc:mysql://localhost:3306/demo_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.demo.entity configuration: map-underscore-to-camel-case: true # 開發(fā)環(huán)境打印SQL生產環(huán)境關閉避免敏感信息泄漏 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl創(chuàng)建一張簡單的用戶表CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, status INT DEFAULT 1, created_at DATETIME ); INSERT INTO sys_user (username, password, status, created_at) VALUES (admin, admin123, 1, NOW()), (zhangsan, pass123, 1, NOW()), (testuser, test123, 0, NOW());新建實體類UserDO字段對應id、username、password、status、createdAt。然后創(chuàng)建Mapper接口和XML文件準備驗證兩類寫法。4. 實操演示#{} 與 ${} 的注入差異先寫一個Mapper接口定義兩個方法一個用#{}查詢用戶一個用${}做模糊查詢// 文件路徑src/main/java/com/example/demo/mapper/UserMapper.java package com.example.demo.mapper; import com.example.demo.entity.UserDO; import org.apache.ibatis.annotations.Param; import java.util.List; public interface UserMapper { UserDO selectUserByUsername(Param(username) String username); ListUserDO searchUserByKeyword(Param(keyword) String keyword); }在src/main/resources/mapper/UserMapper.xml中寫實現(xiàn)?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.example.demo.mapper.UserMapper select idselectUserByUsername resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE username #{username} LIMIT 1 /select select idsearchUserByKeyword resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE %${keyword}% /select /mapper然后寫一個Controller把接口暴露出來方便在本地用瀏覽器或curl測試// 文件路徑src/main/java/com/example/demo/controller/UserController.java package com.example.demo.controller; import com.example.demo.entity.UserDO; import com.example.demo.mapper.UserMapper; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.util.List; RestController public class UserController { private final UserMapper userMapper; public UserController(UserMapper userMapper) { this.userMapper userMapper; } GetMapping(/user/query) public UserDO query(RequestParam String username) { return userMapper.selectUserByUsername(username); } GetMapping(/user/search) public ListUserDO search(RequestParam String keyword) { return userMapper.searchUserByKeyword(keyword); } }啟動項目后先訪問/user/search?keywordzhang控制臺會打印出最終執(zhí)行的SQL。${}方式下日志里能看到SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE %zhang%此時如果傳入一個惡意關鍵字比如http://localhost:8080/user/search?keyword%27%20OR%20%271%27%3D%271%27%20--URL解碼后等價于 OR 11 --拼接后的SQL會變成SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE % OR 11 --%這條SQL執(zhí)行時AND username LIKE %先判斷一次然后OR 11恒為真--后面內容被注釋掉最終返回所有status 1的用戶。這說明${}把外部輸入直接變成了SQL語法的一部分確實存在注入風險?，F(xiàn)在再用/user/query?username%27%20OR%20%271%27%3D%271%27%20--測試#{}接口。觀察日志MyBatis最終生成的SQL是SELECT id, username, password, status FROM sys_user WHERE username ? AND status 1傳給username參數(shù)的是完整字符串 OR 11 --數(shù)據(jù)庫只把它當作一個普通值去匹配查詢結果為null。這就是預編譯帶來的效果同樣一段用戶輸入在#{}里是參數(shù)在${}里是SQL代碼。有一點需要提醒日志中看到“帶占位符的SQL”和“綁定參數(shù)后的SQL”可能不是同一個形式。MyBatis的StdOutImpl會打印帶?的preparing語句和設置參數(shù)的日志要結合兩行一起看才能判斷最終執(zhí)行內容。很多人在排查注入問題時只盯著第一行忽略了參數(shù)綁定部分容易誤判。5. 有 #{} 為什么還要設計 ${}動態(tài)SQL的真實場景既然${}存在注入風險為什么MyBatis還要保留它原因在于SQL語句中有一部分內容不是“值”而是“結構”結構無法用占位符替代。在JDBC的PreparedStatement中?只能替換值不能替換表名、列名、排序字段、GROUP BY字段這一類結構性內容。你可以試寫這樣一條SQLSELECT * FROM ? WHERE ? ?數(shù)據(jù)庫根本無法預編譯因為FROM后面需要的是表名不是字符串值。表名屬于SQL語法結構的一部分。實際開發(fā)中常見的${}場景有三個。第一個場景動態(tài)排序字段。列表頁常見的“按創(chuàng)建時間倒序”“按用戶名排序”如果把排序字段直接傳給#{}生成的SQL會變成ORDER BY created_at DESC數(shù)據(jù)庫不會報錯但排序不會生效因為這種寫法比較的是常量字符串而不是字段名。這種情況下只能把字段名拼進SQL也就是用${}。select idselectUserOrderBy resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status, created_at FROM sys_user WHERE status 1 ORDER BY ${orderColumn} ${orderDir} /select第二個場景動態(tài)表名。分庫分表或多租戶場景下同一個接口可能需要查詢order_202401、order_202402這類物理表。表名無法作為參數(shù)占位只能拼接到SQL里select idselectFromTable resultTypecom.example.demo.entity.OrderDO SELECT * FROM ${tableName} WHERE user_id #{userId} AND order_status #{orderStatus} /select第三個場景某些模糊查詢或自定義SQL片段。雖然模糊查詢可以用CONCAT(%, #{keyword}, %)安全實現(xiàn)但遇到非常復雜的動態(tài)SQL片段需要拼進WHERE條件時開發(fā)者容易圖省事直接用${}。從安全角度看這類需求多數(shù)能用if標簽和#{}完成不應該成為使用${}的理由。關鍵問題來了上面這些場景必須使用${}但${}又不安全項目里應該怎么處理答案很簡單對${}的入參做白名單校驗。任何外部輸入在進入${}之前都必須在代碼層校驗字符串合法性。以排序字段為例可以定義一個Map白名單// 文件路徑src/main/java/com/example/demo/common/SqlGuard.java package com.example.demo.common; import java.util.HashMap; import java.util.Map; public class SqlGuard { private static final MapString, String SORT_COLUMN_MAP new HashMap(); static { SORT_COLUMN_MAP.put(id, id); SORT_COLUMN_MAP.put(username, username); SORT_COLUMN_MAP.put(createdAt, created_at); } public static String resolveSortColumn(String input) { String column SORT_COLUMN_MAP.get(input); if (column null) { throw new IllegalArgumentException(非法排序字段: input); } return column; } }然后在Service層調用Mapper之前做轉換String safeColumn SqlGuard.resolveSortColumn(request.getSortColumn()); userMapper.selectUserOrderBy(safeColumn, safeDir);對于表名同理維護一張“允許訪問的表清單”只有命中的表名才能進入${}。這樣既保留了動態(tài)SQL的靈活性又把注入風險限制在可控范圍內。從框架設計角度看MyBatis把${}開放出來本質是給開發(fā)者一個選擇權。它默認開發(fā)者知道自己拼的是什么。一旦外部輸入能影響${}的內容安全責任就從框架轉移到了應用層代碼。責任邊界清晰但風險也集中。6. MyBatis與MyBatis-Plus這個問題有什么不同討論MyBatis的#{}和${}時經常會被問到MyBatis-Plus。MyBatis-Plus是MyBatis的增強工具封裝了通用CRUD、條件構造器、分頁插件等能力。它并沒有改變#{}和${}的底層機制只是在多數(shù)簡單場景下開發(fā)者不再需要手寫Mapper XML。MyBatis-Plus的條件構造器QueryWrapper可以這樣用QueryWrapperUserDO wrapper new QueryWrapper(); wrapper.eq(username, username) .like(keyword, keyword);它會自動生成參數(shù)化的SQL底層還是預編譯安全性和手寫#{param}一致。但在涉及排序時orderByAsc、orderByDesc方法接收的是字符串字段名這些字段名最終也會進入SQL結構wrapper.orderByAsc(sortColumn);如果sortColumn來自前端不做白名單校驗一樣存在SQL注入風險。所以MyBatis-Plus不是安全免死金牌它只是把常見CRUD封裝得更方便遇到結構型SQL片段時開發(fā)者仍然要遵循同樣的防護原則。另外一個常見區(qū)別是手寫MyBatis的XML更適合復雜查詢和SQL調優(yōu)MyBatis-Plus的Wrapper更適合單表簡單查詢。面試時如果被問到“MyBatis和MyBatis-Plus的區(qū)別”可以從封裝程度、CRUD便捷性、XML控制力、代碼侵入性等角度展開但要記住兩者在#{}和${}的安全機制上是一致的。7. 常見問題與排查思路實際開發(fā)中跟#{}、${}相關的報錯和安全問題并不少。下面整理幾個高頻問題。問題現(xiàn)象可能原因排查方式解決方案使用#{}傳排序字段排序不生效字段名被當作字符串常量不是列名查看MyBatis日志中的SQL是否出現(xiàn)單引號改用${}并做白名單校驗使用${}傳表名傳入后SQL報錯表名中混入了特殊字符或SQL片段打印完整SQL檢查表名部分表名白名單校驗禁止外部直接傳表名模糊查詢用${}后出現(xiàn)注入且結果異常用戶輸入中含有OR、--等SQL關鍵字檢查方法入參和日志中拼接后的SQL改用CONCAT(%, #{keyword}, %)MyBatis控制臺不打印SQLlog-impl未配置或日志級別不匹配檢查application.yml的log-impl配置開發(fā)環(huán)境配置stdout.StdOutImpl生產環(huán)境關閉參數(shù)中包含單引號${}方式直接報錯拼接后的SQL引號不成對查看異常棧中的SQL片段優(yōu)先使用#{}避免字符串拼接相同SQL在#{}下性能不如${}每次生成不同SQL文本預編譯緩存失效觀察數(shù)據(jù)庫預處理語句緩存命中和執(zhí)行計劃盡量固定SQL文本結構部分通過白名單限制在少量常量內在這些問題里真正影響安全性的是“是否把外部參數(shù)直接拼進了SQL結構”。排查時第一步不是看代碼邏輯而是先定位最終執(zhí)行的SQL長什么樣。MyBatis日志、PreparedStatement的參數(shù)綁定日志、MySQL慢查詢日志都能幫你還原問題現(xiàn)場。需要補充一個容易踩的坑有人說“我用了${}但沒出現(xiàn)注入因為我對參數(shù)做了轉義”。這種思路不可靠。轉義是黑名單思維SQL注入繞過手段很多比如內聯(lián)注釋、編碼轉換、數(shù)據(jù)庫函數(shù)拼接等。更穩(wěn)妥的做法是白名單校驗或避免使用${}而不是試圖把所有攻擊Payload都擋在字符串過濾外面。8. 最佳實踐與工程建議寫MyBatis項目時建議直接把下面幾條規(guī)則納入團隊開發(fā)規(guī)范。第一條能用#{}就不用${}。值類型參數(shù)全部走#{}無論是查詢條件、插入值還是更新值。SQL注釋里也可以注明“此處禁止使用${}”減少誤用。第二條必須用${}時入參必須通過白名單校驗。排序字段、表名、列名分別維護一張白名單表不在名單內的輸入直接拒絕。校驗邏輯放在Service層不要放在Mapper接口里這樣接口調用方無法繞過。第三條數(shù)據(jù)庫賬號遵循最小權限原則。應用連接數(shù)據(jù)庫的賬號只給SELECT、INSERT、UPDATE、DELETE權限不給DROP、ALTER、CREATE等DDL權限。即使SQL被注入攻擊者能做的事也會被限制在DML層面。權限設計是縱深防御的一部分不應該依賴SQL寫法兜底。第四條MyBatis打印SQL只允許出現(xiàn)在開發(fā)環(huán)境。生產環(huán)境配置log-impl為空或使用日志框架且級別設為WARN避免SQL參數(shù)中的敏感信息寫進日志文件。很多數(shù)據(jù)泄露事件不是數(shù)據(jù)庫被攻破而是日志文件被拖走里面躺著完整SQL和用戶參數(shù)。第五條代碼評審時重點審查包含${}的XML文件?？梢酝ㄟ^腳本或靜態(tài)掃描工具搜索項目中的${}逐個確認入參來源和校驗邏輯。建議把白名單校驗方法統(tǒng)一放在工具類里例如SqlGuard減少散落各處的重復邏輯。第六條涉及多數(shù)據(jù)源或分庫分表時動態(tài)表名場景要格外謹慎。分表規(guī)則一般在代碼層算好再把計算后的表名傳入Mapper不要在SQL里根據(jù)用戶輸入拼表名。如果分表插件已經支持自動路由優(yōu)先用插件能力不要手寫動態(tài)表名。第七條定期檢查數(shù)據(jù)庫預處理語句緩存。大量使用${}會產生不同SQL文本降低預編譯語句的緩存命中率。當SQL文本量增長明顯時優(yōu)先審視是否有字段誤用了${}而不是盲目調大數(shù)據(jù)庫緩存。除了這些規(guī)則還建議把防注入知識做成團隊內部分享。面試里問#{}和${}不是目的真正要的是候選人對安全邊界有感知。工程上的安全不是靠單個API實現(xiàn)而是靠使用習慣、權限隔離、日志管控、評審機制共同組成的。9. 總結面試這樣回答更有深度如果面試官問你“有#{}為什么還要設計${}”可以按這個思路回答。先講機制#{}會編譯為JDBC預編譯占位符?參數(shù)由數(shù)據(jù)庫驅動綁定不會改變SQL語句結構${}是純字符串替換等同于把外部輸入直接拼進SQL文本存在SQL注入風險。再講設計原因預編譯占位符只能替換“值”不能替換“結構”。動態(tài)SQL里的排序字段、表名、列名屬于SQL結構部分無法用?占位所以MyBatis提供了${}來滿足這類需求。但框架不能判斷傳入的結構是否可信只能由開發(fā)者通過白名單校驗、代碼評審等方式保證安全。最后講實踐項目里默認用#{}遇到結構型參數(shù)才用${}并且所有${}入參必須經過白名單校驗。數(shù)據(jù)庫賬號最小權限、生產環(huán)境關閉SQL日志、代碼評審關注XML中的${}這些是配套的縱深防御措施。這套回答既有底層原理又有框架設計動機還有工程實踐明顯比“#{}安全、${}不安全”這種一句話回答更能體現(xiàn)水平。面試之外的現(xiàn)實問題其實更值得注意能不能把規(guī)則落地到團隊里。如果你下次看到同事在動態(tài)排序代碼里直接拼接前端傳來的字段名建議把本文的白名單方案發(fā)給他這比簡單說一句“別用${}”要有說服力得多。 MyBatis #{}與${}的區(qū)別：預編譯原理、SQL注入風險與動態(tài)SQL實戰(zhàn)
面試場景里有一個問題出現(xiàn)頻率很高而且很多候選人答不到點上MyBatis 里#{}和${}有什么區(qū)別為什么已經有了安全的#{}還要設計一個容易被SQL注入的${}如果只回答“#{}是預編譯${}是字符串拼接”面試官大概率還會追問那預編譯為什么能防注入字符串拼接為什么危險動態(tài)排序、動態(tài)表名的需求到底怎么處理這種追問能快速區(qū)分“背過八股文”和“真正在項目里寫過MyBatis”的人。這篇文章從JDBC預編譯機制講起用一個最小工程演示#{}和${}在同樣一條SQL上的差異再分析${}在動態(tài)SQL里的真實使用場景最后給出白名單校驗、日志配置、權限控制等工程建議。讀完你不僅知道怎么答還能知道項目中踩到類似問題怎么排查。1. 面試官問這個問題到底想考察什么先說結論這道題考察的不是“記沒記住兩個符號的區(qū)別”而是三件事。第一對SQL注入原理的理解。SQL注入為什么能發(fā)生因為用戶輸入被拼接成了SQL語法的一部分改變了語句原本的執(zhí)行語義。如果只是數(shù)據(jù)庫查詢結果變了那叫數(shù)據(jù)問題如果SQL結構被改變那才是安全問題。很多候選人能說出“SQL注入就是把惡意SQL拼進去”但說不清楚拼進去之后SQL引擎到底發(fā)生了什么。第二對JDBCPreparedStatement的理解。MyBatis的#{}最終會生成JDBC預編譯占位符?這是安全的基本前提。如果連預編譯、占位符、參數(shù)綁定這幾個概念都不熟說明底層功底不足。第三對框架設計取舍的理解。MyBatis不是不知道${}危險它依然保留這個能力因為SQL里有“值”和“結構”兩類內容。值可以參數(shù)化結構不能。這就是面試官想聽的“設計原因”而不是簡單一句“用來拼接的”。所以準備這道題時不要背答案要先建立一條完整鏈路用戶輸入 → MyBatis解析 → JDBC SQL構造 → 數(shù)據(jù)庫執(zhí)行。每一步都可能成為攻擊面也都有對應的防御手段。2. SQL注入的本質與 #{} 的安全原理先看一個經典的登錄場景。后端要校驗用戶名和密碼SQL寫成這樣SELECT * FROM sys_user WHERE username admin AND password 123456如果密碼是用戶輸入拼接出來的攻擊者輸入下面的字符串 OR 11 --拼接后SQL變成SELECT * FROM sys_user WHERE username admin AND password OR 11 --OR 11恒為真注釋符號--把后面的SQL注釋掉。這條語句在數(shù)據(jù)庫里執(zhí)行時實際生效的條件只剩WHERE 11等同于查詢全表。這就是SQL注入的最典型例子核心在于輸入內容進入了SQL語句的語法結構層而不是被當作一個普通參數(shù)值。JDBC里對應有兩種寫法。第一種是字符串拼接// 錯誤示例拼接SQL String sql SELECT * FROM sys_user WHERE username username AND password password ; Statement statement connection.createStatement(); ResultSet rs statement.executeQuery(sql);這種方式下用戶輸入直接嵌入SQL文本數(shù)據(jù)庫會把整個字符串當作可執(zhí)行SQL解析。第二種是預編譯// 安全示例預編譯 參數(shù)綁定 String sql SELECT * FROM sys_user WHERE username ? AND password ?; PreparedStatement ps connection.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs ps.executeQuery();?是占位符setString()把參數(shù)值交給數(shù)據(jù)庫驅動處理。數(shù)據(jù)庫先解析SQL結構再綁定參數(shù)。用戶輸入無論包含多少單引號、注釋符、關鍵字都只是某個占位符的值不會改變SQL結構。MyBatis的#{}本質上就是第二種方式。下面這兩條XML中的SQL效果相同select idselectUserByUsername resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE username #{username} AND status 1 /selectMyBatis會把#{username}替換成?然后在執(zhí)行時通過PreparedStatement綁定實參。攻擊者輸入 OR 11 --最終傳遞到數(shù)據(jù)庫的SQL是SELECT id, username, password, status FROM sys_user WHERE username ? AND status 1綁定參數(shù)后username的值就是那一長串字符它只會跟username字段做等值比較不會變成OR條件。有一點需要補充預編譯防注入的前提是SQL語句結構在預編譯階段已經固定。如果SQL本身存在動態(tài)拼接比如后面的${}那結構就是變化的預編譯機制也無法保護不可信的結構部分。#{}和${}的差異可以匯總成下表對比項#{}${}實現(xiàn)方式預編譯占位符?字符串直接替換SQL注入風險低參數(shù)不會進入SQL語法層高輸入可能改變SQL結構適用場景條件值、查詢參數(shù)、插入值表名、排序字段、列名等結構部分使用方式#{param}${param}性能相同SQL可復用預編譯語句每次拼接新SQL緩存收益有限調試可讀性日志中顯示占位符日志中顯示完整SQL3. 環(huán)境準備與最小工程搭建為了直觀驗證#{}和${}的差異我們搭建一個Spring Boot MyBatis的最小演示工程。在進行任何SQL注入驗證時務必使用本地測試數(shù)據(jù)庫不要在生產環(huán)境或未授權系統(tǒng)上操作。假設你本機已有JDK和MySQL環(huán)境。JDK版本、Spring Boot版本、MySQL版本以你本機實際環(huán)境為準本文重點是演示通用思路不需要強綁定某個版本。首先創(chuàng)建一個Spring Boot項目引入MyBatis依賴。在pom.xml中加入dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version請?zhí)鎿Q為項目實際可用版本/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency如果你的項目是基于Spring Boot 3.xMyBatis官方推薦使用mybatis-spring-boot-starter的最新版本如果是Spring Boot 2.x使用對應兼容的舊版本。版本差異不影響本文核心結論。接著在src/main/resources/application.yml中配置數(shù)據(jù)源和MyBatis日志spring: datasource: url: jdbc:mysql://localhost:3306/demo_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.demo.entity configuration: map-underscore-to-camel-case: true # 開發(fā)環(huán)境打印SQL生產環(huán)境關閉避免敏感信息泄漏 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl創(chuàng)建一張簡單的用戶表CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, status INT DEFAULT 1, created_at DATETIME ); INSERT INTO sys_user (username, password, status, created_at) VALUES (admin, admin123, 1, NOW()), (zhangsan, pass123, 1, NOW()), (testuser, test123, 0, NOW());新建實體類UserDO字段對應id、username、password、status、createdAt。然后創(chuàng)建Mapper接口和XML文件準備驗證兩類寫法。4. 實操演示#{} 與 ${} 的注入差異先寫一個Mapper接口定義兩個方法一個用#{}查詢用戶一個用${}做模糊查詢// 文件路徑src/main/java/com/example/demo/mapper/UserMapper.java package com.example.demo.mapper; import com.example.demo.entity.UserDO; import org.apache.ibatis.annotations.Param; import java.util.List; public interface UserMapper { UserDO selectUserByUsername(Param(username) String username); ListUserDO searchUserByKeyword(Param(keyword) String keyword); }在src/main/resources/mapper/UserMapper.xml中寫實現(xiàn)?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.example.demo.mapper.UserMapper select idselectUserByUsername resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE username #{username} LIMIT 1 /select select idsearchUserByKeyword resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE %${keyword}% /select /mapper然后寫一個Controller把接口暴露出來方便在本地用瀏覽器或curl測試// 文件路徑src/main/java/com/example/demo/controller/UserController.java package com.example.demo.controller; import com.example.demo.entity.UserDO; import com.example.demo.mapper.UserMapper; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.util.List; RestController public class UserController { private final UserMapper userMapper; public UserController(UserMapper userMapper) { this.userMapper userMapper; } GetMapping(/user/query) public UserDO query(RequestParam String username) { return userMapper.selectUserByUsername(username); } GetMapping(/user/search) public ListUserDO search(RequestParam String keyword) { return userMapper.searchUserByKeyword(keyword); } }啟動項目后先訪問/user/search?keywordzhang控制臺會打印出最終執(zhí)行的SQL。${}方式下日志里能看到SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE %zhang%此時如果傳入一個惡意關鍵字比如http://localhost:8080/user/search?keyword%27%20OR%20%271%27%3D%271%27%20--URL解碼后等價于 OR 11 --拼接后的SQL會變成SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE % OR 11 --%這條SQL執(zhí)行時AND username LIKE %先判斷一次然后OR 11恒為真--后面內容被注釋掉最終返回所有status 1的用戶。這說明${}把外部輸入直接變成了SQL語法的一部分確實存在注入風險?，F(xiàn)在再用/user/query?username%27%20OR%20%271%27%3D%271%27%20--測試#{}接口。觀察日志MyBatis最終生成的SQL是SELECT id, username, password, status FROM sys_user WHERE username ? AND status 1傳給username參數(shù)的是完整字符串 OR 11 --數(shù)據(jù)庫只把它當作一個普通值去匹配查詢結果為null。這就是預編譯帶來的效果同樣一段用戶輸入在#{}里是參數(shù)在${}里是SQL代碼。有一點需要提醒日志中看到“帶占位符的SQL”和“綁定參數(shù)后的SQL”可能不是同一個形式。MyBatis的StdOutImpl會打印帶?的preparing語句和設置參數(shù)的日志要結合兩行一起看才能判斷最終執(zhí)行內容。很多人在排查注入問題時只盯著第一行忽略了參數(shù)綁定部分容易誤判。5. 有 #{} 為什么還要設計 ${}動態(tài)SQL的真實場景既然${}存在注入風險為什么MyBatis還要保留它原因在于SQL語句中有一部分內容不是“值”而是“結構”結構無法用占位符替代。在JDBC的PreparedStatement中?只能替換值不能替換表名、列名、排序字段、GROUP BY字段這一類結構性內容。你可以試寫這樣一條SQLSELECT * FROM ? WHERE ? ?數(shù)據(jù)庫根本無法預編譯因為FROM后面需要的是表名不是字符串值。表名屬于SQL語法結構的一部分。實際開發(fā)中常見的${}場景有三個。第一個場景動態(tài)排序字段。列表頁常見的“按創(chuàng)建時間倒序”“按用戶名排序”如果把排序字段直接傳給#{}生成的SQL會變成ORDER BY created_at DESC數(shù)據(jù)庫不會報錯但排序不會生效因為這種寫法比較的是常量字符串而不是字段名。這種情況下只能把字段名拼進SQL也就是用${}。select idselectUserOrderBy resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status, created_at FROM sys_user WHERE status 1 ORDER BY ${orderColumn} ${orderDir} /select第二個場景動態(tài)表名。分庫分表或多租戶場景下同一個接口可能需要查詢order_202401、order_202402這類物理表。表名無法作為參數(shù)占位只能拼接到SQL里select idselectFromTable resultTypecom.example.demo.entity.OrderDO SELECT * FROM ${tableName} WHERE user_id #{userId} AND order_status #{orderStatus} /select第三個場景某些模糊查詢或自定義SQL片段。雖然模糊查詢可以用CONCAT(%, #{keyword}, %)安全實現(xiàn)但遇到非常復雜的動態(tài)SQL片段需要拼進WHERE條件時開發(fā)者容易圖省事直接用${}。從安全角度看這類需求多數(shù)能用if標簽和#{}完成不應該成為使用${}的理由。關鍵問題來了上面這些場景必須使用${}但${}又不安全項目里應該怎么處理答案很簡單對${}的入參做白名單校驗。任何外部輸入在進入${}之前都必須在代碼層校驗字符串合法性。以排序字段為例可以定義一個Map白名單// 文件路徑src/main/java/com/example/demo/common/SqlGuard.java package com.example.demo.common; import java.util.HashMap; import java.util.Map; public class SqlGuard { private static final MapString, String SORT_COLUMN_MAP new HashMap(); static { SORT_COLUMN_MAP.put(id, id); SORT_COLUMN_MAP.put(username, username); SORT_COLUMN_MAP.put(createdAt, created_at); } public static String resolveSortColumn(String input) { String column SORT_COLUMN_MAP.get(input); if (column null) { throw new IllegalArgumentException(非法排序字段: input); } return column; } }然后在Service層調用Mapper之前做轉換String safeColumn SqlGuard.resolveSortColumn(request.getSortColumn()); userMapper.selectUserOrderBy(safeColumn, safeDir);對于表名同理維護一張“允許訪問的表清單”只有命中的表名才能進入${}。這樣既保留了動態(tài)SQL的靈活性又把注入風險限制在可控范圍內。從框架設計角度看MyBatis把${}開放出來本質是給開發(fā)者一個選擇權。它默認開發(fā)者知道自己拼的是什么。一旦外部輸入能影響${}的內容安全責任就從框架轉移到了應用層代碼。責任邊界清晰但風險也集中。6. MyBatis與MyBatis-Plus這個問題有什么不同討論MyBatis的#{}和${}時經常會被問到MyBatis-Plus。MyBatis-Plus是MyBatis的增強工具封裝了通用CRUD、條件構造器、分頁插件等能力。它并沒有改變#{}和${}的底層機制只是在多數(shù)簡單場景下開發(fā)者不再需要手寫Mapper XML。MyBatis-Plus的條件構造器QueryWrapper可以這樣用QueryWrapperUserDO wrapper new QueryWrapper(); wrapper.eq(username, username) .like(keyword, keyword);它會自動生成參數(shù)化的SQL底層還是預編譯安全性和手寫#{param}一致。但在涉及排序時orderByAsc、orderByDesc方法接收的是字符串字段名這些字段名最終也會進入SQL結構wrapper.orderByAsc(sortColumn);如果sortColumn來自前端不做白名單校驗一樣存在SQL注入風險。所以MyBatis-Plus不是安全免死金牌它只是把常見CRUD封裝得更方便遇到結構型SQL片段時開發(fā)者仍然要遵循同樣的防護原則。另外一個常見區(qū)別是手寫MyBatis的XML更適合復雜查詢和SQL調優(yōu)MyBatis-Plus的Wrapper更適合單表簡單查詢。面試時如果被問到“MyBatis和MyBatis-Plus的區(qū)別”可以從封裝程度、CRUD便捷性、XML控制力、代碼侵入性等角度展開但要記住兩者在#{}和${}的安全機制上是一致的。7. 常見問題與排查思路實際開發(fā)中跟#{}、${}相關的報錯和安全問題并不少。下面整理幾個高頻問題。問題現(xiàn)象可能原因排查方式解決方案使用#{}傳排序字段排序不生效字段名被當作字符串常量不是列名查看MyBatis日志中的SQL是否出現(xiàn)單引號改用${}并做白名單校驗使用${}傳表名傳入后SQL報錯表名中混入了特殊字符或SQL片段打印完整SQL檢查表名部分表名白名單校驗禁止外部直接傳表名模糊查詢用${}后出現(xiàn)注入且結果異常用戶輸入中含有OR、--等SQL關鍵字檢查方法入參和日志中拼接后的SQL改用CONCAT(%, #{keyword}, %)MyBatis控制臺不打印SQLlog-impl未配置或日志級別不匹配檢查application.yml的log-impl配置開發(fā)環(huán)境配置stdout.StdOutImpl生產環(huán)境關閉參數(shù)中包含單引號${}方式直接報錯拼接后的SQL引號不成對查看異常棧中的SQL片段優(yōu)先使用#{}避免字符串拼接相同SQL在#{}下性能不如${}每次生成不同SQL文本預編譯緩存失效觀察數(shù)據(jù)庫預處理語句緩存命中和執(zhí)行計劃盡量固定SQL文本結構部分通過白名單限制在少量常量內在這些問題里真正影響安全性的是“是否把外部參數(shù)直接拼進了SQL結構”。排查時第一步不是看代碼邏輯而是先定位最終執(zhí)行的SQL長什么樣。MyBatis日志、PreparedStatement的參數(shù)綁定日志、MySQL慢查詢日志都能幫你還原問題現(xiàn)場。需要補充一個容易踩的坑有人說“我用了${}但沒出現(xiàn)注入因為我對參數(shù)做了轉義”。這種思路不可靠。轉義是黑名單思維SQL注入繞過手段很多比如內聯(lián)注釋、編碼轉換、數(shù)據(jù)庫函數(shù)拼接等。更穩(wěn)妥的做法是白名單校驗或避免使用${}而不是試圖把所有攻擊Payload都擋在字符串過濾外面。8. 最佳實踐與工程建議寫MyBatis項目時建議直接把下面幾條規(guī)則納入團隊開發(fā)規(guī)范。第一條能用#{}就不用${}。值類型參數(shù)全部走#{}無論是查詢條件、插入值還是更新值。SQL注釋里也可以注明“此處禁止使用${}”減少誤用。第二條必須用${}時入參必須通過白名單校驗。排序字段、表名、列名分別維護一張白名單表不在名單內的輸入直接拒絕。校驗邏輯放在Service層不要放在Mapper接口里這樣接口調用方無法繞過。第三條數(shù)據(jù)庫賬號遵循最小權限原則。應用連接數(shù)據(jù)庫的賬號只給SELECT、INSERT、UPDATE、DELETE權限不給DROP、ALTER、CREATE等DDL權限。即使SQL被注入攻擊者能做的事也會被限制在DML層面。權限設計是縱深防御的一部分不應該依賴SQL寫法兜底。第四條MyBatis打印SQL只允許出現(xiàn)在開發(fā)環(huán)境。生產環(huán)境配置log-impl為空或使用日志框架且級別設為WARN避免SQL參數(shù)中的敏感信息寫進日志文件。很多數(shù)據(jù)泄露事件不是數(shù)據(jù)庫被攻破而是日志文件被拖走里面躺著完整SQL和用戶參數(shù)。第五條代碼評審時重點審查包含${}的XML文件?？梢酝ㄟ^腳本或靜態(tài)掃描工具搜索項目中的${}逐個確認入參來源和校驗邏輯。建議把白名單校驗方法統(tǒng)一放在工具類里例如SqlGuard減少散落各處的重復邏輯。第六條涉及多數(shù)據(jù)源或分庫分表時動態(tài)表名場景要格外謹慎。分表規(guī)則一般在代碼層算好再把計算后的表名傳入Mapper不要在SQL里根據(jù)用戶輸入拼表名。如果分表插件已經支持自動路由優(yōu)先用插件能力不要手寫動態(tài)表名。第七條定期檢查數(shù)據(jù)庫預處理語句緩存。大量使用${}會產生不同SQL文本降低預編譯語句的緩存命中率。當SQL文本量增長明顯時優(yōu)先審視是否有字段誤用了${}而不是盲目調大數(shù)據(jù)庫緩存。除了這些規(guī)則還建議把防注入知識做成團隊內部分享。面試里問#{}和${}不是目的真正要的是候選人對安全邊界有感知。工程上的安全不是靠單個API實現(xiàn)而是靠使用習慣、權限隔離、日志管控、評審機制共同組成的。9. 總結面試這樣回答更有深度如果面試官問你“有#{}為什么還要設計${}”可以按這個思路回答。先講機制#{}會編譯為JDBC預編譯占位符?參數(shù)由數(shù)據(jù)庫驅動綁定不會改變SQL語句結構${}是純字符串替換等同于把外部輸入直接拼進SQL文本存在SQL注入風險。再講設計原因預編譯占位符只能替換“值”不能替換“結構”。動態(tài)SQL里的排序字段、表名、列名屬于SQL結構部分無法用?占位所以MyBatis提供了${}來滿足這類需求。但框架不能判斷傳入的結構是否可信只能由開發(fā)者通過白名單校驗、代碼評審等方式保證安全。最后講實踐項目里默認用#{}遇到結構型參數(shù)才用${}并且所有${}入參必須經過白名單校驗。數(shù)據(jù)庫賬號最小權限、生產環(huán)境關閉SQL日志、代碼評審關注XML中的${}這些是配套的縱深防御措施。這套回答既有底層原理又有框架設計動機還有工程實踐明顯比“#{}安全、${}不安全”這種一句話回答更能體現(xiàn)水平。面試之外的現(xiàn)實問題其實更值得注意能不能把規(guī)則落地到團隊里。如果你下次看到同事在動態(tài)排序代碼里直接拼接前端傳來的字段名建議把本文的白名單方案發(fā)給他這比簡單說一句“別用${}”要有說服力得多。