在构建有序且无重复的对象集合时，HashSet+List组合相较于LinkedHashSet的适用场景有哪些？

嘿，这个问题问得很实在，我在实际项目里也好几次纠结过选哪种实现，除了你提到的微优化场景，其实还有不少架构设计、业务适配层面的核心场景更适合用HashSet+List的组合，给你梳理几个关键的：

• 没法修改目标类的equals/hashCode逻辑
  这绝对是最常见的刚需场景。比如Thing是第三方库提供的类，你没权限修改它的equals方法；或者Thing类默认的equals逻辑是比较所有字段，但你当前业务只需要按ID去重——这时候用LinkedHashSet就完全没辙，因为它依赖元素自身的equals判断。而HashSet+List的组合，完全绕开了对Thing类本身的修改，用独立的ID集合做去重判断，完美适配这种场景。

• 去重规则是业务场景专属的，不能全局生效
  假设系统其他模块里，两个ID相同但其他属性不同的Thing需要被视为不同实例，但当前这个集合只需要按ID去重。如果为了适配这个集合修改Thing的equals/hashCode，会导致其他模块逻辑全部混乱，这是个大问题。而HashSet+List的组合能把这个特定去重规则完全局限在当前类的add方法里，不会污染全局的类行为，这是架构层面的解耦，和微优化完全不沾边。

• 需要在去重流程中插入自定义业务逻辑
  用LinkedHashSet的话，add方法的去重和添加是封装好的黑盒操作，你没法在去重判断前后插入自己的代码。但用HashSet+List的话，你可以在判断setOfThingIds.contains(id)之后、添加到列表之前，自由加入任何自定义逻辑：比如记录重复元素日志、统计重复次数、对Thing做预处理（补充缺失属性），甚至在特定条件下跳过去重——这种灵活性是LinkedHashSet没法比的。

• 去重判断逻辑和元素本身的“相等”语义无关
  比如你判断重复的依据是“两个Thing的ID前缀相同”或者“ID属于同一个业务分组”，这种判断逻辑和Thing对象自身的“相等”完全不是一回事，把它写到Thing的equals里会让方法语义混乱，后续维护者看了会一脸懵。把这种场景专属的判断逻辑放在HashSet+List的add方法里，代码语义会清晰得多，其他开发者一眼就能明白这个集合的去重规则是业务专属的。

你提到的那种微优化（比如避免equals里的重复计算）其实是次要的，上面这些才是真正需要用HashSet+List替代LinkedHashSet的核心原因，全是从代码可维护性、业务适配性、架构解耦的角度出发的。

内容来源于stack exchange