Java 项目里，持久层和认证框架很容易被当成“技术选型问题”。实际落地时，选型不只看框架能力，还要看团队熟悉度、数据库变化频率、SQL 复杂度和权限模型。
MyBatis 适合 SQL 可控的业务系统
MyBatis 的优势是 SQL 清晰、可控，复杂查询和性能优化比较直接。团队熟悉 XML、Mapper、动态 SQL 后，排查问题也比较方便。
它适合：
- SQL 需要精细控制。
- 查询逻辑比较复杂。
- DBA 或开发需要直接审查 SQL。
- 业务系统以关系数据库为核心。
缺点是样板代码较多，字段变化时 Mapper、XML、DTO 容易不同步，需要生成器、代码规范和测试来兜底。
jOOQ 更像类型安全 SQL 构造器
jOOQ 的思路不是隐藏 SQL，而是用 Java API 表达 SQL，并通过代码生成获得类型安全的表、字段和查询能力。
它适合希望在代码里组合复杂 SQL、又不想完全手写字符串的团队。批量更新、动态条件、类型检查和 IDE 补全会比手写 SQL 更舒服。
但 jOOQ 有学习成本，也会把数据库结构和生成代码绑定得更紧。团队已经熟悉 MyBatis 且 SQL 管理成熟时，不一定要为了“更现代”强行切换。
Flyway 解决数据库变更可追踪
Flyway 关注的是数据库迁移，而不是 ORM。它把建表、改字段、加索引、初始化数据这些变化变成版本化脚本。
适合的场景包括：
- 多环境需要同步 schema。
- 线上变更要可追踪。
- 多人协作避免手工改库遗漏。
- 回滚和审计需要明确脚本记录。
数据库变化频繁的项目，迁移工具比“口头记得执行 SQL”可靠得多。
常见 MyBatis 问题要先看绑定关系
Invalid bound statement (not found) 这类问题通常来自 Mapper 接口和 XML 没对应上。
排查顺序可以是：
- namespace 是否等于 Mapper 接口全限定名。
- 方法名是否和 statement id 一致。
- XML 是否被打包进 classpath。
- MapperScan 是否扫描到接口。
- 多模块项目里资源路径是否正确。
这类问题看起来像运行时异常，本质是接口、XML 和构建产物之间的契约断了。
认证框架要看模式和边界
Sa-Token、Spring Security、OAuth2 这些工具解决的层次不同。
简单后台系统可能只需要登录态、角色和权限校验；开放平台或多客户端系统则需要 token、授权码、刷新令牌、资源服务器等更完整模型。
不要只看框架是否强大，要看业务是否真的需要：
- 表单登录还是前后端分离。
- Session 还是 token。
- 单体应用还是多服务鉴权。
- 权限是菜单级、接口级还是数据级。
- 是否要对接第三方授权。
实用结论
持久层和认证框架没有绝对最优。MyBatis 胜在 SQL 可控，jOOQ 胜在类型安全查询，Flyway 胜在 schema 可追踪；认证框架则要匹配业务登录和权限模型。
选型时先看团队能否维护、问题能否排查、变更能否审计。工具再好，如果让团队失去控制感，也会变成长期成本。
