MyBatis 不支持将查询结果直接返回为 Optional 类型，因其无法识别 Optional 为合法结果承载类型，会导致 BindingException 或 InstantiationException；正确做法是 MyBatis 返回原始类型（如 User、IPage<User>），再由 Service 层用 Optional.ofNullable() 封装。
mybatis 本身不支持直接将查询结果返回为 optional 类型——这不是框架设计的用法，强行这么写会导致运行时崩溃或编译/反射异常。问题往往出现在开发者误以为“用 optional<user> 做返回值就能自动包装 null”，结果在 mapper 接口、xml 映射或 mybatisplus 的分页场景中引发连锁故障。
Mapper 接口声明 Optional 会直接失败
MyBatis 的 SQL 执行器依赖 Java 方法签名做参数绑定和结果映射，它只识别基础类型、POJO、集合（List、Map）、分页对象（IPage）等标准返回类型。一旦你这样写：
Optional<User> selectById(@Param("id") Long id);
MyBatis 在解析该方法时无法识别 Optional 为合法结果承载类型，既不会触发结果映射逻辑，也不会抛出明确提示，而是静默跳过或在执行时抛出 BindingException 或 ReflectionException。尤其在 XML 中配置了 resultType 却接口返回 Optional，就会出现 “no Result Maps were found” 这类底层报错。
XML 或注解中 resultType / resultMap 不兼容 Optional
resultType 只接受 Java 类型（如 com.example.User、java.lang.Integer），不能写 java.util.Optional；resultMap 也只描述如何把一行记录转成一个 POJO，不是用来包装可选性的容器。
如果你在 XML 中写了：
<select id="selectById" resultType="java.util.Optional"> ... </select>
MyBatis 会尝试加载 Optional 类并调用其无参构造器创建实例——但 Optional 没有 public 无参构造器，直接抛 InstantiationException。
MyBatis-Plus 分页 + Optional 组合必然报错
MyBatis-Plus 的分页拦截器严格校验方法签名：必须第一个参数是 IPage，且返回值必须是 IPage<T>。若你定义：
Optional<IPage<User>> pageUsers(IPage<User> page);
拦截器根本识别不出这是分页方法，跳过改写 SQL，导致查出全表数据再内存分页，或直接抛 MybatisPlusException: cant found IPage for args!。更糟的是，有些旧版本 MP 甚至会在反射获取泛型时因嵌套 Optional 而 ClassCastException。
正确做法：Optional 仅用于 Service 层封装
Optional 是语义层工具，不是传输层契约。 应始终让 MyBatis 返回原始类型（User、List<User>、IPage<User>），再由业务代码主动包装：
- 单对象查询：用
User user = mapper.selectById(id); return Optional.ofNullable(user); - 列表查询：MyBatis 返回空
List（安全，永不为null），无需 Optional 包装 - 分页查询：返回
IPage<User>，它自身已含getRecords()和getTotal()，无需再套 Optional
这样既符合 MyBatis 的运行机制，又保留了空值语义表达能力，还能避免序列化（如 JSON 输出）时出现 "optional[User{...}]" 这类非预期字符串。
