企业官网建设流程全解析

聊到MyBatis核心配置文件，很多人的状态是“好像会又好像不会”。动态SQL、ResultMap这些能聊半小时，但被问到<environments>标签里environment的id、default、transactionManager、dataSource都是干嘛的，一下子就卡壳了。这个现象太常见了——因为大部分项目早就用Spring Boot把数据源接管了，mybatis-config.xml要么被精简到只剩一个<mappers>，要么干脆被@MapperScan完全替代，environment这块就成了“学过、见过、但从没自己动手配过”的灰色地带。

但说句实在话，environment恰恰是MyBatis配置体系里最像“装配车间”的部分。数据库驱动怎么加载、连接URL指向哪里、用户名密码填什么、连接池用哪套策略、事务边界由谁控制，全部在这里定死。今天这篇文章我就把这一个点彻底拆开，从标签结构到三套数据源策略，从多环境切换到面试常问的源码级细节，一次性讲透。适合正在系统过MyBatis基础的人，也适合面试前想补底子、或者被各种环境类报错折磨过的开发者。

1. environment在MyBatis核心配置文件里的真实位置

1.1 先认清mybatis-config.xml的完整结构

一份完整的MyBatis核心配置文件，标签顺序是有严格规定的，绝对不能乱写。按官方DTD的定义，顺序必须是：properties、settings、typeAliases、typeHandlers、objectFactory、objectWrapperFactory、reflectorFactory、plugins、environments、databaseIdProvider、mappers。<environments>卡在中间偏后的位置，前面是各种类型处理器和工厂的注册，后面是SQL映射文件的加载，它自己负责的只有一件事——数据库会话（SqlSession）从哪来。

这个顺序不是随便定的。environments要引用properties里定义的属性，所以properties必须在它前面；mappers要基于environments建立好的连接去执行SQL，所以必须在它后面。你如果把<mappers>写到<environments>前面，虽然MyBatis启动时不一定马上报错，但等到真正执行SQL时，SqlSessionFactory内部的Environment还没初始化，就会出现各种“找不到数据源”的诡异问题。所以记住一句话：environments是承上启下的中枢，前面是准备工作，后面是业务映射。

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd"> <configuration> <properties resource="jdbc.properties"/> <settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings> <environments default="dev"> <!-- environment节点在这里 --> </environments> <mappers> <mapper resource="mapper/UserMapper.xml"/> </mappers> </configuration>

1.2 为什么实际项目里你很少改它

这里要说一个很多初学者困惑的点：明明MyBatis的核心配置文件里有environments，为什么Spring Boot项目里几乎见不到有人配它？因为在Spring Boot集成方案中，DataSource是由Spring容器创建并管理的，MyBatis的SqlSessionFactory通过SpringManagedTransactionFactory拿到了Spring提供的数据源。这种情况下，mybatis-config.xml里的environments虽然还是会被解析，但它已经被容器“架空”了，真正起作用的连接信息全在application.yml里。

但如果你脱离Spring，回到最原始的MyBatis用法——代码里手动构建SqlSessionFactory，那environment就是绕不开的关口。甚至可以说，能不看教程就写对environments配置的人，才是真正理解了MyBatis的会话管理机制。本文后面讲到的所有内容，在这种手写场景下单拎出来就能用。

2. environment节点拆解：id、default与transactionManager逐个说清

2.1 多个环境并存，default决定谁生效

<environments>标签的default属性指向一个<environment>的id值，两者必须对应上。这个设计解决的是“一套代码多套环境”的问题：开发环境连本地库、测试环境连测试库、生产环境连正式库，三套连接参数都写在配置文件里，通过切换default就能决定当前SqlSessionFactory到底用哪套连接。

我见过不少人把id写成development、test、production这种长名字，没问题，但更推荐直接用dev、test、prod这种简短标识，配合default="dev"读起来一目了然。有一点需要注意：default的取值如果拼错，MyBatis启动时不会立刻报“找不到环境”这种话，而是在你获取SqlSession去执行SQL时才抛出EnvironmentException，错误信息很绕，排查起来费劲。所以写完配置后第一件事就是核对default和id是否完全一致。

<environments default="dev"> <environment id="dev"> <!-- 开发环境 --> </environment> <environment id="test"> <!-- 测试环境 --> </environment> <environment id="prod"> <!-- 生产环境 --> </environment> </environments>

2.2 事务管理器选JDBC还是MANAGED，先想清楚事务边界

每个<environment>内部有两个子节点：<transactionManager>和<dataSource>。transactionManager的type只有两个可选值：JDBC和MANAGED，面试里经常拿这个做文章。

选JDBC，意味着MyBatis内部直接使用java.sql.Connection的commit()、rollback()、close()来管理事务，事务边界是“一次SqlSession内从第一条SQL到提交/回滚”。这种方式简单直接，适合单独使用MyBatis、不引入Spring这类容器管理的场景。

选MANAGED，意思是MyBatis把事务生命周期交给外部容器，它自身不主动提交也不主动回滚。在传统Java EE应用里可能有用，但在Spring项目里要格外小心——事务边界已经被Spring的@Transactional接管了，如果transactionManager配成MANAGED，很容易出现“MyBatis以为有人管事务、Spring也以为事务边界已经提交”的双重误解。

我个人的建议是：拿不准就用JDBC，尤其在纯MyBatis场景下。即便在Spring项目里，也没必要改成MANAGED，因为Spring集成时真正生效的是SpringManagedTransactionFactory，你写在XML里的这个选项更多是留一个初始默认值。踩过一次坑之后我的习惯是——先画清楚事务边界再选事务管理器，而不是随手抄一个配置。

2.3 一个可以直接抄的配置骨架

把开发环境的完整配置摆出来，就是下面这个样子：

<environments default="dev"> <environment id="dev"> <transactionManager type="JDBC"/> <dataSource type="POOLED"> <property name="driver" value="com.mysql.cj.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/mybatis_demo?useUnicode=true&amp;characterEncoding=utf8"/> <property name="username" value="root"/> <property name="password" value="123456"/> </dataSource> </environment> </environments>

注意URL里的&，XML里直接写&是语法错误，必须转义。我在接手别人项目时经常看到有人写jdbc:mysql://localhost:3306/db?useSSL=false&serverTimezone=UTC，结果启动解析XML直接抛异常，就是栽在这个转义上。另外driver和url如果对应不上MySQL版本，比如MySQL 8的驱动类名写成com.mysql.jdbc.Driver，运行时会报ClassNotFoundException。这些不起眼的细节，恰恰是环境类问题的重灾区。

3. dataSource选型：UNPOOLED、POOLED、JNDI到底怎么选

3.1 UNPOOLED：连接随用随建，适合什么场景

UNPOOLED从名字就能看出来，不搞连接池，每次需要数据库连接时直接DriverManager.getConnection()新建一个，用完就关。它的配置很简单，就是最基本的四件套：driver、url、username、password。

什么场景适合UNPOOLED？第一是开发调试阶段，频繁重启应用，连接池缓存一堆连接反而碍事；第二是数据量极小的内部工具、运维脚本，一天跑不了几次SQL，搞连接池纯属浪费内存；第三是某些对连接生命周期有特殊要求的环境，比如测试定时任务里的临时会话，不想让连接池里的老连接带着脏状态复现问题。除此之外，生产环境我强烈不推荐UNPOOLED，因为一次SQL请求就要经历“建立TCP连接、握手认证、断开TCP”全过程，在高并发下连接创建开销会直接拖垮数据库。

虽然叫“无池”，但UNPOOLED也有一些可选的属性可以调，比如driver.encoding之类的，实际用的不多，记住最基础的四件套就够了。

3.2 POOLED：生产环境默认选择，重点参数逐个啃

POOLED是MyBatis内置的简单连接池实现，也是绝大多数生产项目的默认选择。它的核心机制可以理解为“管好一堆连接”：有请求来了，先看池里有没有空闲连接，有就借出去；没有空闲且总数没到上限，就新建一个；都占满了，请求方等一会儿，超时再报错。

<dataSource type="POOLED"> <property name="driver" value="com.mysql.cj.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/mybatis_demo"/> <property name="username" value="root"/> <property name="password" value="123456"/> <property name="poolMaximumActiveConnections" value="10"/> <property name="poolMaximumIdleConnections" value="5"/> <property name="poolMaximumCheckoutTime" value="20000"/> <property name="poolTimeToWait" value="20000"/> <property name="poolMaximumLocalBadConnectionTolerance" value="3"/> </dataSource>

几个关键参数我在项目里都实测过，逐个说：

• poolMaximumActiveConnections：最大活跃连接数，默认10。不是越大越好，数据库自身有max_connections限制，开太多连接会挤爆数据库。我曾经把并发量高的服务这个值调到50，数据库瞬间出现连接超限告警。
• poolMaximumIdleConnections：最大空闲连接数，默认5。空闲连接保留太多就是白占内存，太少了又会频繁创建新连接。
• poolMaximumCheckoutTime：连接被借出的最大时长，默认20000毫秒。这是个防泄漏机制——某段代码拿连接不还，超过这个时间就被强制回收。但注意这个值不是让你救命的，真出现连接未关闭，该查代码还得查。
• poolTimeToWait：拿不到连接时最长等待时间，默认20000毫秒。超时后抛PoolException，提示“已经超时”之类。
• poolPingQuery：连接保活探测SQL，比如SELECT 1；配套poolPingEnabled开关和poolPingConnectionsNotUsedFor空闲时间阈值。

我常用的生产配置是：活跃连接数控制在20以内，等待时间20秒，开启poolPingEnabled设为true，poolPingQuery设为SELECT 1，这样MySQL的wait_timeout把连接断了之后，下次获取时可以先探活再复用，避免拿到死连接。

3.3 JNDI：把自己交给容器管理

JNDI类型适合应用部署在Tomcat、Jetty这类Servlet容器中，数据库连接由容器统一配置和管理，MyBatis通过jndi名称去查找外部数据源。使用方式在<dataSource>里配一个initial_context和data_source属性，比如：

<dataSource type="JNDI"> <property name="data_source" value="java:comp/env/jdbc/mydb"/> </dataSource>

JNDI的优势在于数据源配置对应用透明，运维改数据库地址不用动应用。但代价也很明显——脱离容器就没法跑，本地启动一个main方法直接报找不到JNDI资源。个人意见：除非项目明确跑在容器里且运维体系要求统一管理数据源，否则别选JNDI，维护成本和本地调试成本都偏高。

3.4 三种数据源对比速查

对普通项目来说，POOLED是那个“默认不会错”的选项；UNPOOLED是“轻量但别在生产赌运气”的选项；JNDI则是“企业级约束下的选择”。把这三者的界限搞清楚，面试被问到“MyBatis数据源有哪几种”时，就不再是背答案，而是能讲出各自底层的连接行为差异。

4. 多环境实战：一套配置开发、测试、生产自由切换

4.1 第一步：把环境差异项抽到properties

environment节点里最常变的是数据库连接四件套。如果每个环境都把这些值硬编码在XML里，未来切换环境就要改XML文件，手一抖改错一个字符，诊断成本极高。正确做法是把这些差异项抽到外部jdbc.properties，然后通过<properties>标签引入。

# jdbc.properties dev.driver=com.mysql.cj.jdbc.Driver dev.url=jdbc:mysql://localhost:3306/dev_db dev.username=dev_user dev.password=dev_pass test.driver=com.mysql.cj.jdbc.Driver test.url=jdbc:mysql://192.168.1.100:3306/test_db test.username=test_user test.password=test_pass

然后在mybatis-config.xml里用${}占位符替换：

<properties resource="jdbc.properties"/> <environments default="dev"> <environment id="dev"> <transactionManager type="JDBC"/> <dataSource type="POOLED"> <property name="driver" value="${dev.driver}"/> <property name="url" value="${dev.url}"/> <property name="username" value="${dev.username}"/> <property name="password" value="${dev.password}"/> </dataSource> </environment> </environments>

这样做的直接好处是：环境切换时不需要碰XML结构，只需要改default指向或者替换jdbc.properties文件。

4.2 第二步：用default和id管理环境

default相当于一个总开关。开发时default="dev"，联调测试时改成default="test"，发布前改成default="prod"。但要提醒自己，default是编译期决定的——一旦SqlSessionFactory构建完成，运行期间再改配置文件不会自动生效，必须重启应用。

有些人会在同一份XML里把所有环境节点都写上，用default切换，这在配置文件自解释性上是加分的，但隐患是：所有数据库地址和账号密码都存在一个文件里，安全上并不理想。我的习惯是：本地开发保留dev和test两套，prod环境不写入仓库，由发布流水线在打包时注入。

4.3 第三步：结合构建工具做资源替换

如果觉得default手动切换还是太原始，可以结合Maven的profile来做环境资源替换。思路是给不同环境建不同的配置目录，打包时用对应profile把jdbc.properties过滤进classpath。

<profiles> <profile> <id>dev</id> <properties> <env>dev</env> </properties> </profile> <profile> <id>prod</id> <properties> <env>prod</env> </properties> </profile> </profiles> <build> <resources> <resource> <directory>src/main/resources</directory> </resource> <resource> <directory>src/main/resources-${env}</directory> </resource> </resources> </build>

目录里放src/main/resources-dev/jdbc.properties和src/main/resources-prod/jdbc.properties，执行mvn package -P prod时，生产环境的配置就会被替换进去。这在Spring Boot项目里是常规操作，在纯MyBatis项目里同样适用。每次发布都用构建参数明确指定环境，人肉改配置文件的日子就彻底结束了。

4.4 验证当前到底走的哪个环境

很多人改了配置之后不确定是否生效，其实有两个低成本的验证手段。一个是把日志级别调到DEBUG，观察MyBatis启动时打印的Logging initialized、PooledDataSource、Class name等信息，里面会明确输出当前使用的是哪个数据源URL；另一个是写一个@Test方法，直接通过SqlSessionFactory.getConfiguration().getEnvironment().getId()把当前环境ID打出来。

这两种方式都比“凭感觉”靠谱得多。尤其是排查“改了配置还是连旧库”的问题时，第一步永远是确认当前Environment的ID和数据源URL，而不是上来就怀疑代码逻辑。

5. 常见问题与排查技巧实录

5.1 碰到could not set environment: 150这类报错怎么办

搜索引擎里经常有人搜“could not set environment: 150: operation not permitted while system integrity”，这其实不是MyBatis本身的报错，而是操作系统级别的安全限制。比如在启用了SELinux的Linux发行版上，某个进程尝试对受保护路径做写入或者设置操作时，内核会拒绝并返回150错误。如果你在启动MyBatis相关服务时看到这个报错，优先检查应用的工作目录、临时文件目录是否有写权限，以及SELinux是否拦截了Java进程的文件操作。

排查路径是：先确认报错出现的时间点是不是在初始化Environment前后，然后用dmesg或者/var/log/audit里的记录看是不是安全策略拦截，最后尝试用chcon调整上下文或临时setenforce 0验证（注意生产环境别这么干）。这个问题和environment标签本身没关系，但很多人因为报错关键词里有environment就被带偏了，特别写出来帮大家少走弯路。

5.2 配了environments却不生效的排查思路

“我在XML里明明配置了dev环境，为什么跑起来连的还是另一个库？”这类问题我接过不止一次。汇总几个最常见的根源：

• 第一个：mybatis-config.xml根本没被加载。代码里构建SqlSessionFactory时可能写死了另一个配置路径，或者Spring Boot的mybatis.config-location没有指向这个文件。
• 第二个：classpath里有多个同名配置文件，比如target/classes下的旧文件覆盖了src/main/resources里的新文件，构建时没clean。
• 第三个：配置文件的default拼写错误，或者引用的占位符${dev.url}在jdbc.properties里找不到对应键，MyBatis不会立刻报错，而是生成一个无效值连接默认主机。
• 第四个：Spring Boot场景下，application.yml里Spring的datasource配置优先级高于mybatis-config.xml的environments，所以你以为改了XML，实际生效的还是Spring数据源。

排查时别靠猜，先用4.4里的方法打印真实环境ID，再检查配置加载路径，问题马上就能定位。

5.3 POOLED连接池“借不出连接”的真实案例

有个线上服务，平时运行稳定，某天突然大量请求超时，日志里刷PooledDataSource无法拿到连接。我先看活跃连接数，发现长期满额，再一分析，发现某段代码在获取SqlSession后没有在finally里关闭，导致连接被借出后一直不归还，直到poolMaximumCheckoutTime超时被强制回收。

这类问题的根治方式是代码规范，但临时缓解可以调大poolMaximumCheckoutTime和poolTimeToWait。不过经验告诉我，靠调参续命撑不了多久，还是得把资源释放逻辑补好。花两分钟检查一下自己的代码里有没有SqlSession开着不关的情况，比排查半天配置有用得多。

5.4 从XMLConfigBuilder看environment的解析链路

面试题里常出现“MyBatis核心配置文件是如何被解析的”，这就要用到源码层面的知识了。SqlSessionFactoryBuilder收到配置文件输入流后，会创建XMLConfigBuilder，它在parse()方法里按DTD顺序逐个解析节点。environments由XMLConfigBuilder.environmentsElement(context)方法处理，它会读取default属性，遍历所有environment节点，分别解析出TransactionFactory和DataSource，然后包装成一个org.apache.ibatis.mapping.Environment对象，最后通过configuration.setEnvironment(environment)写入全局配置。

Configuration对象里有个protected Environment environment字段，这个字段是SqlSessionFactory每次创建SqlSession时获取连接的依据。整个链路一句话总结就是：XML → XMLConfigBuilder → Configuration.environment → SqlSession.getConnection()。把这个顺序捋顺了，面试时从配置文件一路讲到连接获取，中间塞得满满的，绝对是加分项。

5.5 环境相关避坑清单

我在本地项目里反复踩过这些坑，整理成清单送给大家：

• 配置文件名一定是mybatis-config.xml，但加载时注意资源路径大小写，Linux下区分大小写，mybatis-config.xml和MyBatis-Config.xml是两个文件。
• driver类的选择要和数据库版本匹配，MySQL 8用com.mysql.cj.jdbc.Driver，MySQL 5.x用com.mysql.jdbc.Driver，配错就报ClassNotFoundException。
• 连接URL里的参数务必做XML转义，&写&，<写<。
• 密码别硬编码在XML里，尤其别提交到Git仓库，用properties外部化或者环境变量注入。
• 多环境都用POOLED时，每个环境的连接池参数也要独立评估，别用一套数值打天下。
• 手工构建SqlSessionFactory时，Environment对象可以被多个Configuration复用，但要注意DataSource内部状态是共享的，多租户场景别把连接池混用。

这些坑单看都不大，但组合起来就是新手阶段最耗时的那部分。

最后分享一个我的配置习惯

改环境配置时，我习惯顺手给每个environment加一行注释标明用途和负责人，比如<!-- dev环境：本地开发库，负责人张三 -->。配置这种东西，当时写了什么以及为什么这么写，过三个月再看基本全忘，注释是给未来的自己留线索。踩过几次配置问题的坑之后，我的体会是：环境类问题看着复杂，本质都是“配置路径、生效优先级、资源释放”三件事。把这三件事的验证手段提前准备好，遇到报错时按顺序检查，绝大多数问题都能在十分钟内定位。希望这篇拆解能帮你把MyBatis核心配置文件里的environment彻底吃透，以后无论是手写配置还是排查问题，心里都有底。