JUnit5中对数据库操作耗时卡控的核心方案是：结合assertTimeout精准约束SQL执行+自定义基类封装统一超时逻辑+@Test(timeout)兜底防御，兼顾细粒度控制、可维护性与全局策略。
JUnit 中对极度消耗资源的数据库操作做耗时卡控，核心思路是：避免单个测试失控拖垮整个测试套件，同时兼顾可维护性和统一策略。直接在每个 @Test 上硬编码 timeout 不现实，尤其当多个测试都涉及慢查询、批量写入或事务回滚模拟时；而用 @Rule Timeout（JUnit4）又无法覆盖 JUnit5 且对 @BeforeEach/@AfterEach 生效过宽。最稳妥的做法是结合 assertTimeout + 自定义基类封装，实现细粒度、可配置、易复用的全局卡控。
用 assertTimeout 替代 @Test(timeout) 做精准控制
JUnit5 的 `assertTimeout` 是函数式断言，只约束传入的 lambda 执行，不干扰测试生命周期其他环节（比如 `@BeforeEach` 初始化连接、`@AfterEach` 清理数据）。这对数据库测试特别关键——你只想卡住“执行 SQL”那段，而不是让连接池初始化也超时。
示例：
- 写法更清晰：
assertTimeout(ofSeconds(3), () -> userDao.batchInsert(users)); - 失败时抛出明确异常，带实际超时差值（如“exceeded timeout of 3 s by 1.2 s”），便于定位慢 SQL
- 支持嵌套调用：可在 service 层测试里卡住 DAO 调用，也可在 DAO 层测试里卡住 JDBC 执行
自定义基类统一封装超时逻辑
把重复的 `assertTimeout` 包装成基类方法，避免每个测试都写样板代码。例如定义 `DbTestBase`：
立即学习“Java免费学习笔记（深入）”；
- 提供带默认超时的模板方法：
protected void runWithTimeout(Runnable task) { assertTimeout(ofSeconds(5), task); } - 支持运行时覆盖：
protected void runWithTimeout(long seconds, Runnable task) { assertTimeout(ofSeconds(seconds), task); } - 可集成连接管理：
protected <t> T runWithTimeout(Supplier<t> supplier) { return assertTimeout(ofSeconds(5), supplier); }</t></t>，适合带返回值的查询
子类直接继承后调用即可，无需重复声明超时值，修改全局阈值只需改基类一处。
配合 @Timeout 注解做兜底防御
基类方法管“业务逻辑段”，`@Test(timeout = ...)` 管“整个测试方法”。两者叠加形成双保险：
- 主逻辑用 `runWithTimeout()` 卡在 5 秒，覆盖 SQL 执行和事务处理
- 整个测试方法加 `@Test(timeout = 10000)`（10 秒），防意外死锁、网络卡顿导致线程挂起
- 这样即使 `@BeforeEach` 中数据库连接卡住（比如连接池耗尽），也会被外层 timeout 拦截，不会无限等待
规避常见陷阱
数据库测试超时容易踩坑，需注意：
- 不要用 @Rule Timeout（JUnit4）或 @ExtendWith(TimeoutExtension.class)（JUnit5）全局生效——它会把 `@BeforeEach` 里的连接获取、建表语句也纳入计时，导致误报
- 避免在超时块内做资源释放——`assertTimeout` 超时后线程被中断，`try-finally` 中的 close 可能不执行，应改用 try-with-resources 或独立清理逻辑
- 区分“合理慢”和“异常慢”——批量插入 10 万条可能需 8 秒，设 timeout=10s 合理；但单条 `SELECT * FROM huge_table WHERE unindexed_col = ?` 耗时 8 秒就该优化索引，而非放宽 timeout
