Configuration 是 MyBatis 运行时动态中枢，非只读快照，承载所有注册中心与执行上下文，其修改实时影响后续 SqlSession；不可深拷贝、不可运行时随意 addMappedStatement；布尔配置项为默认值开关，非全局生效；自定义子类须谨慎重写方法并确保 registry 初始化完整。
Configuration 是 MyBatis 的全局状态容器，不是配置“快照”而是运行时中枢
它不是启动时读完配置文件就封存的只读对象，而是整个 SqlSessionFactory 生命周期内持续被读写、动态更新的中心节点。所有 MapperRegistry、TypeAliasRegistry、InterceptorChain、MappedStatement 都注册或挂载在它身上。一旦你手动调用 configuration.addMapper() 或修改 configuration.setMapUnderscoreToCamelCase(true)，影响会实时透传到后续所有 SqlSession 创建和 SQL 执行中。
常见错误现象：MapperScannerConfigurer 扫描后仍报 Invalid bound statement (not found)，往往是因为你在 SqlSessionFactoryBean 构建完成前，误把 Configuration 当作不可变对象，提前缓存了它的 MappedStatement 引用；或者在多数据源场景下，多个 SqlSessionFactory 共享了同一个 Configuration 实例（实际不会，但自定义工厂时容易误造）。
- 不要对
Configuration做深拷贝或序列化——它持有大量非线程安全的可变集合（如mappedStatements是ConcurrentHashMap，但interceptors是普通List） - 扩展插件（
Interceptor）必须在SqlSessionFactory构建前注册，因为Configuration.addInterceptor()会直接写入内部列表，后期无法热加载 -
Configuration的environment属性决定事务管理器和数据源，切换数据源不能靠改它——要换SqlSessionFactory，而不是复用一个 factory 去改它的 configuration.environment
为什么不能在运行时随意调用 addMappedStatement()？
MyBatis 不提供运行时动态注册 SQL 的公开 API，addMappedStatement() 是 package-private 方法，仅限框架内部使用。强行通过反射调用，会绕过 SQL 解析、参数映射校验、缓存初始化等关键流程，导致后续执行抛 BindingException 或返回空结果。
使用场景：极少数需要动态生成 SQL 的场景（如低代码报表引擎），正确做法是用 XMLConfigBuilder 或 MapperBuilderAssistant 模拟构建流程，而非直操作 configuration.mappedStatements。
- 直接 put 到
configuration.mappedStatementsmap 中，会导致SqlSession查不到该语句——因为MapperRegistry和MapperProxyFactory并不感知这个变更 -
MappedStatement构造依赖Configuration自身的类型处理器、语言驱动、脚本语言等上下文，脱离 builder 构造极易出现NullPointerException在getBoundSql()阶段 - MyBatis 3.4+ 对
MappedStatement增加了id校验（要求全限定名唯一），重复 id 会静默覆盖，且无日志提示
Configuration 中的 boolean 配置项（如 useGeneratedKeys）到底作用于哪一层？
这些开关不是全局开关，而是「默认值传递开关」：它们只在解析 XML 或注解时作为缺省值参与 MappedStatement 构建，一旦语句自身声明了对应属性（如 <insert useGeneratedKeys="true">），就会覆盖 Configuration 的设置。换句话说，configuration.setUseGeneratedKeys(true) 只对没显式声明该属性的语句生效。
性能影响：这类布尔值本身无开销，但开启 useGeneratedKeys 或 cacheEnabled 后，会触发额外 JDBC 调用或缓存逻辑，真正影响性能的是下游行为，不是 Configuration 字段读取。
-
mapUnderscoreToCamelCase是例外：它既影响 XML 解析阶段的 resultType 映射，也影响运行时ResultSetHandler的自动赋值，且无法被单条语句覆盖 -
callSettersOnNulls控制是否给 null 值调用 setter，会影响反射开销，尤其在大量字段为 null 的宽表查询中建议设为 false -
configuration.getLocalCacheScope()返回的是LocalCacheScope枚举，不是布尔值，但常被误当作开关——它决定一级缓存生命周期（STATEMENT或SESSION），改它会立刻改变所有未提交SqlSession的缓存行为
自定义 Configuration 子类时最容易被忽略的兼容性断裂点
MyBatis 内部大量使用 instanceof Configuration 判断做分支逻辑（比如 DefaultSqlSession 构造时检查是否为 Configuration 类型以决定是否启用延迟加载）。如果你继承 Configuration 并重写关键方法（如 getMappedStatement()），但没同步更新 MapperRegistry 或 CachedMap 等关联状态，就会出现「查得到语句但执行时报 BindingException: Parameter 'xxx' not found」这类诡异问题。
真实踩坑案例：某团队为支持多租户 SQL 改写，继承 Configuration 并重写了 getMappedStatement()，但忘了代理 mappedStatements 的 get 操作——导致 MapperMethod 解析参数时拿不到原始 MappedStatement 的 ParameterMap，最终参数绑定失败。
- 不要重写
getMapper()、addMapper()这类注册方法，除非你完整复刻MapperRegistry的线程安全逻辑 -
Configuration的构造函数会初始化大量 registry（TypeHandlerRegistry、LanguageDriverRegistry），子类必须显式调用super()，否则这些 registry 为 null - MyBatis 3.5+ 引入了
ObjectFactory和Plugin的泛型增强，若子类涉及泛型擦除（如MyConfiguration<T>），可能破坏插件链的pluginAll()调用顺序
