MyBatis中#{}与${}的底层解析机制探析

> ### 摘要 > 本文深入剖析MyBatis中`#{}`与`${}`的底层解析机制：`#{}`经由`ParameterMapping`和`TypeHandler`处理，最终封装为安全的预编译参数，参与`BoundSql`构建；而`${}`则绕过参数化流程，直接执行字符串替换，存在SQL注入风险。文章重点揭示`BoundSql`如何在`SqlSource`解析阶段区分二者，并强调`#{}`的类型安全转换路径及其对动态SQL的保障作用。 > ### 关键词 > MyBatis,#{}解析,${}拼接,BoundSql,SQL注入 ## 一、MyBatis参数解析机制基础 ### 1.1 MyBatis框架概述及参数绑定机制简介 MyBatis作为一款轻量级的持久层框架，其核心价值不仅在于简化JDBC操作，更在于以高度可定制的方式桥接Java对象与关系型数据库。在这一桥梁之上，参数绑定机制是保障SQL安全与灵活性的关键枢纽——它决定了动态SQL如何被解析、如何与运行时参数交互、又如何最终抵达数据库执行引擎。不同于传统ORM对映射关系的全自动化封装，MyBatis选择将控制权部分交还给开发者，通过`#{}`与`${}`两种语法显式区分“参数化”与“文本内联”，从而在表达力与安全性之间划出一条清晰而不可逾越的边界。这种设计并非权宜之计，而是源于对SQL执行本质的深刻理解：真正的安全不来自屏蔽细节，而来自对每处变量注入路径的透明化、可追溯、可验证。正因如此，参数绑定机制不是MyBatis的附属功能，而是其架构哲学的具象体现——它让每一次SQL生成，都成为一次有意识的技术抉择。 ### 1.2 #{}与${}的基本用法与区别 `#{}`与`${}`表面仅是一对符号之差，实则承载着截然不同的语义契约与执行命运。`#{}`代表受控的参数占位，它触发MyBatis完整的类型安全解析链：从`ParameterMapping`的元数据注册，到`TypeHandler`的序列化转换，最终汇入预编译语句（PreparedStatement）的参数槽位；而`${}`则是纯粹的文本透传，跳过所有类型校验与SQL预编译流程，在SQL字符串构建阶段即完成硬编码式拼接。这种差异直接决定着SQL的命运——前者将用户输入严格隔离于执行计划之外，后者却将其毫无保留地暴露于SQL解析器的原始上下文中。当开发者写下`WHERE name = #{userName}`，系统默默构筑起一道防火墙；而一旦改写为`WHERE name = '${userName}'`，那道墙便轰然倒塌，留下直通数据库的裸露通道。这不是语法糖的取舍，而是信任边界的郑重声明。 ### 1.3 MyBatis参数解析的核心组件 支撑`#{}`与`${}`差异化行为的，是一组精密协作的核心组件：`SqlSource`作为SQL抽象的源头，负责识别并分类占位符类型；`BoundSql`则是解析结果的最终载体，它不仅封装SQL语句文本，更关键地记录了`ParameterMapping`列表——这些映射条目正是`#{}`参数得以被安全绑定的凭证；而`TypeHandler`则承担类型转换的守门人角色，确保Java对象能准确、无歧义地映射为JDBC兼容的SQL类型。三者共同构成MyBatis参数解析的铁三角：`SqlSource`判别意图，`BoundSql`固化契约，`TypeHandler`落实转换。尤其值得注意的是，`BoundSql`的构建过程本身即是一次静态审查——它在SQL执行前就已明确区分哪些位置接受参数化绑定、哪些位置仅允许字面量替换，从而将风险识别前置至编译期而非运行期。 ### 1.4 参数解析流程的整体架构 MyBatis参数解析并非线性流水线，而是一个分层决策的架构：最上层是`Mapper XML`或`@Select`注解中的原始SQL模板，经`XMLLanguageDriver`或`AnnotationLanguageDriver`解析后，交由`SqlSourceBuilder`进行首次语义切分；随后进入关键的`parse`阶段——此时`#{}`被提取为`ParameterMapping`对象并注入`BoundSql`的参数映射集合，而`${}`则被立即执行字符串替换，直接融入SQL文本；最终生成的`BoundSql`实例，既包含净化后的SQL字符串，也携带完整的参数绑定契约。这一架构的精妙之处在于，它将“安全”与“危险”在逻辑层面彻底解耦：`#{}`路径全程处于MyBatis类型系统与JDBC预编译机制的双重保护之下，而`${}`路径则被明确标记为“需人工审慎使用”的例外通道。正因如此，理解该流程，不只是掌握技术细节，更是习得一种在动态SQL世界中守护数据疆域的方法论。 ## 二、BoundSql的构建过程解析 ### 2.1 BoundSql的定义与核心属性 BoundSql是MyBatis中承载SQL解析结果的核心数据结构，它并非一段简单的字符串，而是一份经过语义校验与契约固化后的“可执行契约”。其本质，是`SqlSource`在解析阶段对原始SQL模板进行类型化裁决后的权威快照——既封装了最终用于执行的SQL文本，也明确记录了所有`#{}`参数的绑定位置、顺序与类型元信息。其中，`sql`字段存储经净化与替换后的SQL语句；`parameterMappings`列表则如一份严谨的签证名录，逐条登记着每个`#{}`所对应的`ParameterMapping`对象，包含参数名、JDBC类型、`TypeHandler`引用等关键契约要素；而`additionalParameters`则作为动态上下文容器，承载`<bind>`等语法引入的衍生变量。值得注意的是，BoundSql本身不参与执行，却为后续PreparedStatement的参数设置提供了不可篡改的蓝图——它让每一次SQL执行，都建立在编译期已确认的安全边界之上。 ### 2.2 BoundSql构建的详细步骤 BoundSql的构建始于`SqlSource`的`getBoundSql()`方法调用，该过程严格遵循“识别—分离—固化”三阶逻辑：首先，`SqlSourceBuilder`扫描原始SQL文本，依据`#{}`与`${}`的语法特征进行标记性切分；随后，所有`${}`表达式被立即求值并完成字符串拼接，直接写入待生成的SQL文本；而所有`#{}`则被剥离为独立的`ParameterMapping`对象，注入`BoundSql`的`parameterMappings`集合，并同步注册其关联的`TypeHandler`；最后，整合净化后的SQL字符串、参数映射列表及附加参数上下文，封装为不可变的`BoundSql`实例。这一过程发生在SQL首次加载或Mapper刷新时，具有强确定性与零运行时歧义——它拒绝任何“边执行边解析”的模糊地带，将安全责任前置到框架初始化阶段，使开发者得以在代码提交前，就看清每一条SQL背后的参数契约。 ### 2.3 解析过程中的关键类和方法 驱动BoundSql构建的核心类链高度内聚：`SqlSourceBuilder`作为入口，调用`parse()`方法启动解析；其内部依赖`ParameterExpression`对`#{}`进行语法提取，并委托`ParameterMappingTokenHandler`构造`ParameterMapping`对象；而`${}`的处理则由`TextSqlNode`的`apply()`方法直接接管，通过`GenericTokenParser`完成即时字符串替换；最终，`RawSqlSource`或`DynamicSqlSource`将聚合结果交由`BoundSql`构造器完成实例化。尤为关键的是`ParameterMapping`类——它不仅是参数元数据的载体，更在`BoundSql`中构成类型安全的锚点，确保后续`PreparedStatement`的`setXXX()`调用严格匹配预设的JDBC类型与位置索引。这些类与方法之间没有冗余跳转，每一环都精准对应一种语义承诺：`#{}`走向类型守门，`${}`走向文本透传，界限清晰如刻。 ### 2.4 参数绑定过程中的数据流转 从Mapper接口调用到数据库执行，参数数据沿一条被精心设计的单向通道流转：用户传入的参数对象（如Map、POJO或单值）首先进入`DefaultSqlSession`的执行链，经`MapperMethod`封装为`Map<String, Object>`形式；随后，该参数映射被传递至`BindingParamter`，作为`BoundSql.getParameterMappings()`遍历的上下文源；在`PreparedStatementHandler`中，系统依`parameterMappings`的顺序，逐个提取参数值，交由对应`TypeHandler`序列化为JDBC兼容类型，并最终通过`PreparedStatement`的类型化setter（如`setString()`、`setLong()`）写入预编译语句的占位符槽位。整个过程杜绝字符串拼接，杜绝类型推断，杜绝运行时解析——`#{}`的每一次落位，都是`BoundSql`契约与JDBC协议的一次静默握手；而一旦路径中混入`${}`，这条受控通道便被强行截断，数据以裸字符串形态直抵SQL解析器，瞬间瓦解预编译机制构筑的全部防线。 ## 三、#{}的底层解析机制 ### 3.1 #{}的预编译处理机制 当开发者在SQL模板中写下`#{userName}`，这短短三个字符便悄然启动一场静默而庄严的契约缔结仪式——它不声张，却拒绝妥协；不渲染，却层层设防。`#{}`并非简单的占位符号，而是MyBatis向JDBC PreparedStatement发出的一份正式委托：将参数值隔离于SQL语法结构之外，交由数据库驱动以二进制协议安全传递。这一机制的核心，在于彻底剥离“文本拼接”与“语义执行”的耦合——SQL语句的骨架在`BoundSql`构建阶段即已固化，所有`#{}`位置被抽象为逻辑占位符，不参与字符串解析，不暴露于SQL词法分析器的视野之内。正因如此，哪怕传入恶意构造的`' OR '1'='1`，它也永远不会成为SQL语法的一部分，而仅作为独立的数据块，被`PreparedStatement`以`setString(1, "...")`的方式注入预编译语句的第1号槽位。这不是侥幸的防御，而是架构级的免疫设计：从`SqlSource`识别开始，到`BoundSql`封装完成，再到`PreparedStatementHandler`执行落位，`#{}`始终行走在一条被类型系统与JDBC规范双重校验的专用车道上。 ### 3.2 参数值如何被转换为预编译占位符 参数值通往预编译占位符的旅程，是一次精确到字节的定向迁移。它始于`BoundSql.getParameterMappings()`所定义的顺序契约——每个`#{}`按出现次序生成唯一索引，构成不可变的位置坐标系；继而由`PreparedStatementHandler`依序遍历该映射列表，从用户传入的参数对象（如Map或POJO）中提取对应键名的值；随后，该原始值被交付至其绑定的`TypeHandler`，完成Java类型到JDBC类型的确定性转换；最终，`PreparedStatement`依据`ParameterMapping`中声明的JDBC类型（如`Types.VARCHAR`），调用匹配的`setXXX()`方法，将序列化后的值写入预编译语句的指定参数槽位。整个过程杜绝字符串插值，杜绝运行时类型推断，杜绝任意位置的值覆盖——参数不是“填入”SQL，而是“绑定”到语句结构中早已预留的、类型明确的接口之上。这种刚性流转，使每一次`#{}`的落位，都成为一次对SQL执行计划完整性的无声确认。 ### 3.3 TypeHandler在#{}解析中的作用 `TypeHandler`是`#{}`安全链条中最沉默却最不可替代的守门人。它不参与SQL文本的拼装，却决定着参数值能否被正确解码为数据库可理解的语言；它不介入`BoundSql`的构建，却在`ParameterMapping`注册时便已刻下类型契约的烙印。当`#{age}`被解析为`ParameterMapping`，其关联的`TypeHandler`即被静态绑定——若`age`为`Integer`，则默认使用`IntegerTypeHandler`，确保`setInt()`被精准调用；若为自定义枚举，则由开发者指定的`EnumTypeHandler`完成序列化映射。这种绑定发生在SQL初始化阶段，而非执行时刻，因而杜绝了运行时类型歧义。更关键的是，`TypeHandler`的职责不仅是转换，更是校验：它拒绝非法值、拦截空指针、统一空值策略（如`null`映射为`NULL`而非`'null'`字符串），从而在数据跨域之前，就筑起第一道语义防火墙。没有`TypeHandler`，`#{}`只是空洞的占位；有了它，`#{}`才真正成为类型安全的信标。 ### 3.4 预编译SQL的生成过程 预编译SQL的生成，并非在`Connection.prepareStatement()`调用那一刻才开始，而是在`BoundSql`诞生之时便已完成逻辑奠基。`BoundSql.sql`字段所承载的，从来不是最终执行的SQL字符串，而是经`#{}`剥离、`${}`替换后、可供JDBC驱动直接编译的“洁净模板”——其中所有`#{}`均已退化为标准问号占位符（`?`），且顺序严格对应`parameterMappings`列表索引。当`PreparedStatementHandler`持此模板调用`connection.prepareStatement(boundSql.getSql())`，数据库驱动接收到的是一条语法完整、结构稳定、无任何变量内联的SQL语句；随后，框架依`parameterMappings`顺序，逐个调用`PreparedStatement`的类型化setter方法，将参数值以二进制协议注入对应槽位。这一过程彻底规避了SQL解析器对参数内容的二次扫描——数据库只编译一次模板，只执行一次绑定，所有参数值均以数据流形式传输，与SQL语法树物理隔离。正因如此，预编译SQL不是性能优化技巧，而是MyBatis对“代码即契约”这一信念最坚硬的技术兑现。 ## 四、${}的直接拼接逻辑 ### 4.1 ${}的直接字符串拼接原理 `${}`不是占位，而是刺穿抽象层的锋刃——它拒绝等待、拒绝封装、拒绝任何中间态的缓冲。在`SqlSourceBuilder`的`parse()`流程中，`${}`被`GenericTokenParser`以毫秒级精度识别，并立即交由`TextSqlNode.apply()`执行求值：此时，参数值尚未进入MyBatis类型系统，也未触碰JDBC预编译机制，它只是被当作纯文本，粗暴而直接地嵌入SQL模板的原始字节流中。没有`ParameterMapping`的登记，没有`TypeHandler`的校验，没有`BoundSql.parameterMappings`的契约约束——`${userName}`在解析完成那一刻，已化作`'张三'`或`'admin' OR '1'='1`，成为SQL字符串不可分割的一部分。这种拼接不讲逻辑，不问类型，不设边界；它像一把未经淬火的刀，锋利却易折，高效却致命。正因如此，`${}`从不参与`BoundSql`的参数映射构建，它的存在本身，就是对“安全默认”原则的一次主动让渡。 ### 4.2 参数值的直接替换过程 `${}`的替换发生在`BoundSql`诞生前的最前端——当`SqlSourceBuilder`扫描到`$`符号，它不暂停、不验证、不记录，只做一件事：取值、转字符串、拼接。哪怕传入的是一个`List<String>`，它也会调用`toString()`生成`[a, b, c]`并原样塞进SQL；哪怕传入`null`，它也不会触发空值处理策略，而是直接拼出`NULL`或空字符串，取决于Java对象本身的`toString()`行为。这个过程完全绕过`BindingParameter`的规范化包装，跳过`ParameterMapping`的索引编排，更无视`PreparedStatement`的类型接口。参数值不是被“绑定”，而是被“烙印”——以明文形态，刻在SQL语法树的枝干上，与关键字、运算符、括号共享同一解析层级。数据库收到的，不再是结构清晰的预编译指令，而是一条已被篡改、已被注入、已被动态重写的原始语句——它的每一次执行，都是对SQL解析器信任边界的重新测试。 ### 4.3 与#{}解析路径的差异 `#{}`走的是契约之路：从`SqlSource`识别开始，经`ParameterMapping`注册、`BoundSql`固化、`TypeHandler`转换，最终落位于`PreparedStatement`的类型化槽位——全程受控、可追溯、不可篡改。而`${}`走的是透传之路：它在`SqlSourceBuilder`阶段即被剥离出安全轨道，未经任何元数据登记，不生成`ParameterMapping`，不进入`parameterMappings`列表，不触发`TypeHandler`，不依赖`PreparedStatement`的二进制协议——它只在字符串层面完成一次裸露的、不可逆的文本缝合。二者在`BoundSql`构建阶段便已分道扬镳：`#{}`贡献的是“参数契约”，`${}`贡献的是“SQL文本”。前者让MyBatis能说：“此参数必以VARCHAR传入第1位”；后者让MyBatis只能沉默：“此处内容，由你全权负责”。这不是实现方式的不同，而是设计哲学的根本对立——一个将安全内建为架构基因，一个将风险外显为开发者责任。 ### 4.4 ${}使用场景分析 `${}`并非缺陷，而是留白——它只为那些必须由SQL引擎动态解析的元信息而存在：表名、列名、排序字段、`IN`子句中的枚举值列表……这些内容无法被参数化，因为它们不属于“数据”，而是“结构”。例如`SELECT * FROM ${tableName}`中，`${tableName}`决定的是查询作用域，而非查询条件；又如`ORDER BY ${sortField} ${sortOrder}`中，`${sortField}`参与的是SQL语法生成，而非值绑定。此时，`${}`是唯一合法出口，但亦是最危险的出口——它要求开发者自行承担输入校验、白名单过滤、上下文隔离的全部责任。MyBatis从未承诺保护它，正如手术刀不承诺不伤人；它存在的意义，不是降低门槛，而是标记禁区：凡用`${}`之处，必有代码之外的防御纵深——那是业务规则的校验、是配置中心的约束、是运维层的SQL审计，而非框架层的自动兜底。 ## 五、SQL注入风险与防范策略 ### 5.1 SQL注入的基本原理与危害 SQL注入并非代码的偶然失守，而是语义边界的彻底溃散——当用户输入未经隔离地混入SQL语法结构，数据库便不再执行“查询”，而是在执行“被篡改的指令”。其本质，是将本应作为数据的内容，诱骗SQL解析器误判为命令的一部分：一个单引号可截断字符串字面量，一对`OR '1'='1`能绕过全部权限校验，一段`UNION SELECT`甚至可撬开另一张表的门扉。这种攻击不依赖系统漏洞，只依赖开发者对“文本”与“结构”界限的模糊；它不挑拣数据库类型，因所有遵循SQL标准的引擎，都共享同一套词法与语法解析逻辑。危害早已超越数据泄露——账户接管、批量删库、横向渗透、勒索加密……每一次成功的注入，都是对“信任”这一底层契约的公开绞杀。而最令人窒息的，是它的隐蔽性：一条看似无害的`${userName}`，在日志里静默如常，在监控中毫无异常，直到某天凌晨三点，备份服务器突然报出`TRUNCATE TABLE users`的执行记录。 ### 5.2 #{}如何有效防止SQL注入 `#{}`不是一道防火墙，而是一道不可逾越的语义鸿沟——它从不把参数当作“字符串”来对待，而是将其视为独立于SQL语法的生命体，拥有自己的类型、位置与契约。在`BoundSql`构建阶段，`#{}`已被剥离为`ParameterMapping`，其存在本身即宣告：此处不接受文本拼接，只接受二进制绑定。当`PreparedStatement`最终生成，SQL模板中只剩冰冷的`?`，而参数值则通过`setString()`、`setInt()`等强类型方法，以JDBC协议规定的二进制流注入预编译槽位。数据库引擎收到的，永远是两条分离的信道：一条承载结构（SQL语句），一条承载数据（参数值）；前者被编译一次、缓存复用，后者被严格校验、类型锁定。哪怕传入`admin' -- `，它也只会成为`setString(1, "admin' -- ")`中的一个普通字符串值，绝无可能干扰`WHERE username = ?`的语法完整性。这不是侥幸的过滤，而是架构级的免疫：`#{}`让SQL注入在技术上成为不可能事件——因为攻击者根本无法让恶意内容进入SQL解析器的视野。 ### 5.3 ${}使用中的SQL注入风险 `${}`是MyBatis亲手递出的双刃剑，锋刃朝外，柄却交由开发者赤手紧握。它不提供任何缓冲、不触发任何校验、不生成任何映射——参数值在`SqlSourceBuilder.parse()`的毫秒间，便已化作原始字节，焊死在SQL字符串的骨架之上。此时，`' OR '1'='1`不再是待处理的数据，而是`WHERE name = '`之后紧随其后的合法语法；`users; DROP TABLE orders-- `也不再是危险输入，而是`SELECT * FROM ${tableName}`最终生成的`SELECT * FROM users; DROP TABLE orders-- `。风险不在代码行数，而在语义层级：`${}`让数据库第一次真正“看见”了用户输入，并赋予其与`SELECT`、`FROM`同等的语法权重。更致命的是，这种风险无法被`TypeHandler`拦截、无法被`BoundSql`记录、无法被`PreparedStatement`规避——它发生在预编译之前，发生在契约建立之前，发生在一切安全机制启动之前。使用`${}`，等于主动关闭MyBatis最坚固的防护盾，将SQL执行权，连同全部责任，一并移交至业务层输入校验的窄门之内。 ### 5.4 实际案例分析：SQL注入与防范 某电商平台订单导出功能曾采用`${sortField}`实现动态排序，未加白名单校验。攻击者构造请求参数`sortField=update_time ASC, (SELECT COUNT(*) FROM users WHERE username='admin') > 0 -- `，成功触发子查询并回显管理员存在状态；后续更利用`sortField=id; DROP TABLE order_items-- `直接清空订单明细表。事故根源并非MyBatis缺陷，而是`${}`被用于本应结构固定的字段名场景——`sortField`实为有限枚举（`create_time`, `update_time`, `status`），却未通过`Enum.valueOf()`或配置中心白名单强制约束。修复方案并非弃用`${}`，而是重建防御纵深：在Controller层校验`sortField`是否属于预设枚举集，Service层拒绝非白名单值，同时将排序逻辑移至应用层内存排序，彻底消除SQL结构动态化需求。此案昭示一个冷峻事实：`#{}`守护的是数据边界，`${}`暴露的是结构边界；而真正的安全，永远诞生于框架能力与人工审慎的交汇点——那里没有银弹，只有层层设防的清醒。 ## 六、性能对比与实践应用 ### 6.1 #{}与${}的性能对比 在纯粹的执行路径长度上，`${}`看似轻盈——它跳过`ParameterMapping`注册、绕开`TypeHandler`转换、不生成`BoundSql.parameterMappings`，仅需一次字符串替换便完成SQL组装；而`#{}`则需穿越`SqlSourceBuilder`解析、`ParameterMapping`构建、`BoundSql`封装、`PreparedStatement`绑定等多重关卡。然而，这种“快”，是透支安全信用的裸奔式提速。真正的性能，从来不是单次调用的毫秒差，而是系统在高并发、长周期、多变输入下的稳定吞吐能力。`#{}`所依赖的预编译机制，使数据库可缓存执行计划、复用解析结果、规避重复语法校验——每一次相同结构的SQL执行，都只需注入新参数，无需重走词法分析、语法树构建、查询优化全流程；而`${}`驱动的SQL则每次生成全新语句文本，迫使数据库反复编译、重新估算执行成本、频繁刷新计划缓存。当流量洪峰涌来，`#{}`构筑的是可预测的确定性，`${}`释放的却是不可控的熵增。这不是速度之争，而是可持续性之辨：前者以微小的初始化代价，换取长期稳定的执行效率；后者以即时的轻量幻觉，埋下性能雪崩的伏笔。 ### 6.2 预编译与直接拼接的执行效率 预编译SQL的效率优势，并非来自MyBatis的魔法，而是对JDBC规范与数据库内核的虔诚遵循。当`BoundSql.sql`中所有`#{}`被统一置换为`?`，数据库接收到的是一条结构恒定、参数剥离的洁净模板；其执行计划一旦生成，即可被缓存数小时乃至数日——后续请求仅需填充二进制参数流，跳过全部昂贵的解析与优化环节。反观`${}`拼接出的SQL，哪怕仅字段名微调（如`${sortField}=create_time`变为`${sortField}=update_time`），也会生成语义迥异的新语句，触发完整编译链路。在OLTP场景下，这意味着每秒数百次的重复语法分析、索引选择重估、执行路径重建；在连接池紧张时，更可能因计划缓存污染导致内存溢出。MyBatis不参与SQL执行，却通过`#{}`将开发者锚定在高效轨道上——它不承诺更快，但确保每一次执行，都站在前一次优化的肩膀之上。 ### 6.3 参数解析对性能的影响 参数解析本身并非性能瓶颈，而是性能边界的刻度尺。`SqlSourceBuilder.parse()`阶段对`#{}`与`${}`的分流处理，在首次加载Mapper时完成，属一次性静态开销；真正影响性能的，是解析结果所决定的后续执行路径。`#{}`导向`BoundSql`的契约化结构，使`PreparedStatementHandler`能以O(1)复杂度按序绑定参数，全程无反射、无动态类型推断、无字符串操作；而`${}`虽省去映射构建，却将不可控的字符串拼接压力转嫁给JVM字符串池与数据库SQL解析器——尤其当嵌套多层`<if>`、`<foreach>`与`${}`混用时，`TextSqlNode.apply()`需反复创建临时字符串对象，引发高频GC，同时数据库端承受着语句碎片化带来的缓存失效风暴。参数解析的“成本”，最终显影于运行时的资源消耗图谱：它不体现在代码行间，而沉淀在CPU使用率曲线里、堆内存波动中、慢SQL告警频次上。 ### 6.4 最佳实践选择建议 选择`#{}`还是`${}`，从来不是技术选型，而是责任划分仪式。`#{}`应成为绝对默认——只要涉及用户输入、业务变量、运行时值，必须经由`#{}`进入SQL世界；它不是妥协，而是对数据本质的尊重。`${}`仅在三类场景下可谨慎启用：一是确需动态表名或列名（如分库分表路由），且已通过白名单校验（如枚举`Enum.valueOf()`强制转换）；二是`IN`子句中固定长度的枚举列表（如`WHERE status IN (${statusList})`），且`statusList`由后台配置而非前端传入；三是极简脚本类工具（如数据库迁移脚本），并接受离线审计约束。每一次`${}`的敲击，都应伴随一行注释：“此处已人工验证输入来源可信、范围可控、上下文隔离”——这不是代码规范，而是向未来自己发出的郑重提醒。MyBatis从不阻止你走向悬崖，但它早已在`#{}`的每一道类型转换里，为你铺好了归途的砖石。 ## 七、高级应用与优化建议 ### 7.1 MyBatis参数解析的优化方向 MyBatis的参数解析机制早已不是简单的“替换”或“绑定”，而是一场在抽象与执行之间持续校准的精密平衡。当前`#{}`与`${}`的二元分治，虽以清晰边界守护了安全底线，却也在动态SQL日益复杂的今天，显露出表达力与可维护性的张力——当一个查询需同时动态切换表名、排序字段与条件参数时，开发者被迫在`#{}`的牢笼与`${}`的悬崖间反复横跳，每一次妥协，都是对架构一致性的无声让渡。真正的优化方向，并非削弱`#{}`的安全契约，亦非为`${}`加装虚幻的防护罩，而是拓展参数解析的语义疆域：让`#{}`能承载更多元的上下文（如允许`#{@table('user')}`触发编译期表名白名单校验），让`BoundSql`的构建过程支持可插拔的解析策略（如引入`SqlNode`级别的类型感知替换器），甚至让`TypeHandler`不再仅服务于值转换，而成为结构元信息的协同校验者。这不是功能堆砌，而是将“安全”从被动防御升维为主动设计——当参数解析开始理解业务意图，而非仅识别语法符号，MyBatis才真正从工具，走向伙伴。 ### 7.2 高级参数绑定技巧 高级不在于炫技，而在于让每一次参数落位，都成为一次深思熟虑的契约签署。`<bind>`标签是被低估的静默力量——它不拼接、不透传，却能在`BoundSql`构建前，将复杂表达式（如`@date.format('yyyy-MM-dd')`）固化为受控变量，再以`#{}`方式注入，既规避`${}`风险，又突破单值绑定局限；`@SelectProvider`与`@InsertProvider`则将SQL生成权交还给Java逻辑，在方法体内调用`StringBuilder`拼接时，仍可对动态片段施加白名单过滤与长度截断，使`${}`的使用退守至绝对可信的封闭域；而`Map<String, Object>`参数中的`@Param`别名机制，更在`ParameterMapping`注册阶段就为每个`#{}`锚定唯一语义身份，避免多参数同名冲突导致的绑定错位。这些技巧的共性，在于它们从不挑战`#{}`与`${}`的根本分工，而是在各自轨道上，把“可控”刻得更深、把“责任”划得更清——因为真正的高级，是让自由，始终行走在清醒划定的边界之内。 ### 7.3 自定义TypeHandler的实现 自定义`TypeHandler`不是代码的增补，而是信任的延伸——当MyBatis默认的`StringTypeHandler`无法理解“加密手机号”或“带时区的时间戳”，开发者便亲手锻造一把专属钥匙，插入`ParameterMapping`那枚精密锁芯。实现过程看似简单：继承`BaseTypeHandler<T>`，覆写`setNonNullParameter()`与`getNullableResult()`，将Java对象与JDBC类型间的转换逻辑具象化；但其灵魂，却藏在`null`值的哲学抉择里——是映射为SQL `NULL`，还是空字符串？是抛出`IllegalArgumentException`，还是静默降级？每一个`if (parameter == null)`分支，都是对业务语义的一次郑重确认。更深远的意义在于，它让`#{}`从此不止于“安全”，更迈向“精准”：当`JsonTypeHandler`将`Order`对象序列化为JSON字符串并存入`TEXT`字段，`BoundSql`依然洁净如初，`PreparedStatement`依旧只认`setString()`，而数据库却已悄然接纳了结构化数据的新范式。这把钥匙不开锁，只校准；不绕过规则，只深化契约。 ### 7.4 复杂场景下的参数处理策略 复杂场景从不考验语法熟练度，而直击设计勇气——当一个查询需同时处理分页偏移量、多条件组合筛选、嵌套JSON字段匹配与租户隔离标识时，参数不再是扁平的键值对，而是一张立体的关系网。此时，`#{}`必须升维为“参数域”：将`PageRequest`封装为`PageParam`对象，其内部`offset`与`limit`字段通过`@Param("page")`统一注入，确保`BoundSql.parameterMappings`中位置索引的确定性；多条件筛选则交由`Criteria`类聚合，每个条件字段经`@Param("criteria")`传递后，在XML中以`<if test="criteria.name != null">AND name = #{criteria.name}</if>`展开，让`TypeHandler`逐层校验而非字符串拼接；至于租户ID这类全局约束，则通过`ThreadLocal`注入`Interceptor`，在`prepare()`阶段自动追加`AND tenant_id = #{_tenantId}`，使其成为`BoundSql.sql`中不可剥离的洁净片段。所有策略的底层逻辑一以贯之：绝不让任何用户输入或运行时变量，以`${}`形态触碰SQL骨架——因为复杂，从来不是放纵的理由，而是让`#{}`的契约，覆盖得更广、扎得更深。 ## 八、总结 本文系统剖析了MyBatis中`#{}`与`${}`的底层解析机制，揭示二者在`BoundSql`构建阶段的根本分野：`#{}`经由`ParameterMapping`与`TypeHandler`纳入预编译参数体系，实现类型安全的动态绑定；而`${}`则绕过全部参数化流程，在SQL字符串层面完成即时拼接，直接暴露于SQL注入风险。文章强调，`BoundSql`不仅是SQL文本的容器，更是参数契约的权威固化——其`parameterMappings`列表明确界定哪些位置受JDBC预编译保护，哪些位置需开发者自主设防。对`#{}`的深入解析，凸显了MyBatis将安全内建于架构设计的哲学；对`${}`的警示性剖析，则重申了“结构动态化”必须伴随严格白名单与上下文隔离的实践铁律。最终，防范SQL注入并非依赖单一语法选择，而是源于对`#{}`契约的坚守、对`${}`边界的敬畏，以及在二者交汇处所构建的纵深防御体系。