From d8eaa16682cf180e9563d6be05fb43057daf6c07 Mon Sep 17 00:00:00 2001
From: yeg <1347747024@qq.com>
Date: 星期一, 12 十月 2026 10:34:14 +0800
Subject: [PATCH] feat(merchant): 后台纳管外部进件商户并支持解绑

---
 docs/agents/testing.md |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/docs/agents/testing.md b/docs/agents/testing.md
index 681989f..54cabe9 100644
--- a/docs/agents/testing.md
+++ b/docs/agents/testing.md
@@ -125,6 +125,25 @@
 的回退在途）状态。以后新写这类「后台任务只处理了我这条」的用例，照它的做法先腾窗口，不要再依赖测试库的
 累积状况。
 
+## 「Too many connections」：也是环境相关，已修（2026-10-12）
+
+全量跑着跑着，**后加载**的那个用例类会整类报错，根因是：
+
+```
+Unable to obtain connection from database: ...
+message from server: "Too many connections"   (SQL State 08004)
+```
+
+每个 `@SpringBootTest` 的上下文都缓存到整个 JVM 结束、各自持有一个 Hikari 连接池，而 Hikari 的
+`minimum-idle` 默认等于 `maximum-pool-size`（10），**启动时就把 10 条连接建满**。一次全量会累积十几个
+上下文（2026-10-12 实测 15 个），150 条空闲连接正好把测试库那个 8.0 实例的 `max_connections=151`
+吃光。测试 profile 现在把 `spring.datasource.hikari.minimum-idle` 钉成 `1`（见
+`src/test/resources/application-test.yml`），空闲上下文只留一条、按需再涨，连接池语义不变。
+**别把它改回去**：症状是「明明只加了几个测试，却有整整一个类的用例全挂」，很容易被误判成自己引入的回归。
+
+判断依据：报错里出现 `Too many connections` 就是它，与代码无关（同一次全量里，挂的总是**靠后**加载的
+上下文，而不是某个具体用例的逻辑）。
+
 ## 测试库跑不起来时，先看 WSL（2026-09-17 实测）
 
 测试库那个 8.0.36 实例跑在 **WSL 的 docker 里**（发行版 `Ubuntu-26.04`，容器 `talent-card-mysql-1`，

--
Gitblit v1.7.1