在 junit 5 测试中，当被测方法抛出的异常消息包含动态拼接的集合元素（如 `b, c, d`）且顺序不确定时，直接用 `assertthrows(..., "expected message")` 会因元素遍历顺序不稳定而偶发失败；本文提供两种稳定、原生、无需第三方库的解决方案：固定迭代顺序构造输入数据，或对异常消息进行结构化解析断言。
在使用 Preconditions.checkArgument 等校验逻辑时，若错误消息依赖 Set 的 stream().filter(...).iterator() 遍历结果（如 Joiner.on(", ").join(...)），其输出顺序由底层 Set 实现决定。HashSet 不保证迭代顺序，导致测试中异常消息如 "The strings b, c, d..." 可能变为 "The strings d, b, c..."，使基于完整字符串匹配的 assertThrows 断言不可靠。
✅ 方案一：控制输入，确保顺序可预测（推荐）
最简洁、可维护性最高的方式是在测试中主动提供有序集合，而非依赖实现细节。LinkedHashSet 按插入顺序迭代，完全符合需求：
@Test
void funcSubSet_throwsWithConsistentMessage() {
// 使用 LinkedHashSet 替代 HashSet，保证 filter 后 stream 的顺序稳定
Set setA = new LinkedHashSet<>(Arrays.asList("a", "b", "c", "d"));
Set setB = new LinkedHashSet<>(Arrays.asList("a"));
// 注入到被测对象（假设 funcSubSet 支持参数化或可重写）
// 或通过重构将集合作为参数传入：funcSubSet(setA, setB)
IllegalArgumentException ex = assertThrows(
IllegalArgumentException.class,
() -> funcSubSet(setA, setB)
);
assertEquals(
"The strings b, c, d are present in setA but not in setB",
ex.getMessage()
);
} ? 关键点：此方案要求被测方法支持外部传入集合（即解耦数据构造与业务逻辑），这既是测试友好的设计，也提升了代码内聚性与可读性。
✅ 方案二：解析式断言 —— 对异常消息做语义校验
若无法修改被测方法签名或输入构造方式（如 setA/setB 是私有字段且不可注入），则应放弃“全字符串匹配”，转为校验消息结构 + 关键内容存在性：
@Test
void funcSubSet_throwsWithCorrectContentRegardlessOfOrder() {
Exception ex = assertThrows(Exception.class, () -> funcSubSet());
String msg = ex.getMessage();
// 校验固定前缀与后缀
assertTrue(msg.startsWith("The strings "), "Message must start with 'The strings '");
assertTrue(msg.endsWith(" are present in setA but not in setB"),
"Message must end with ' are present in setA but not in setB'");
// 提取中间变量部分（去除前后固定文本）
String variablesPart = msg.substring(
"The strings ".length(),
msg.length() - " are present in setA but not in setB".length()
).trim();
// 分割并校验每个缺失元素是否都存在（忽略顺序和空格）
Set expectedMissing = Set.of("b", "c", "d");
Set actualMissing = Arrays.stream(variablesPart.split(",\\s*"))
.map(String::trim)
.collect(Collectors.toSet());
assertEquals(expectedMissing, actualMissing,
"Missing elements mismatch: expected " + expectedMissing + ", got " + actualMissing);
} 该方案完全基于 JUnit 5 原生 Assertions，不引入 AssertJ、Hamcrest 等额外依赖，同时具备强健性：即使消息中多出空格、换行或标点微调，只要语义正确即可通过。
⚠️ 注意事项与最佳实践
- 避免 HashSet 在测试敏感路径中：生产代码中若消息顺序影响用户体验或日志分析，也建议统一使用 LinkedHashSet 或 TreeSet（按字典序）。
- 不要用 contains() 粗粒度校验：例如 assertTrue(msg.contains("b") && msg.contains("c")) 易受误匹配干扰（如 "ab" 被误认为含 "b"），应先分割再精确比对。
- 优先重构而非绕过问题：异常消息顺序不可控本质是测试脆弱性的信号，推动将集合构造逻辑外移，比在测试中不断修补断言更可持续。
综上，控制输入顺序是首选策略；结构化解析是兜底方案。二者均立足 JUnit 5 原生能力，兼顾可靠性、可读性与工程可维护性。
