用HashSet而非ArrayList做黑名单判断，因前者查存在性为O(1)，后者为O(n)；但需确保hashCode/equals正确实现、避免null误用、注意大小写/空格/编码统一，并考虑线程安全与初始化性能。
为什么用 HashSet 而不是 ArrayList 做黑名单判断
因为黑名单校验本质是“这个值在不在集合里”，属于典型的成员存在性检查。用 ArrayList 时每次都要遍历，平均时间复杂度是 O(n)；而 HashSet 底层靠哈希表，理想情况下查一个元素只要 O(1)——尤其当黑名单有几百上千条时，性能差距立马拉满。
但注意：HashSet 的常数级不是白来的，它依赖良好的 hashCode() 和 equals() 实现。如果黑名单项是自定义对象（比如 BlacklistEntry），没重写这两个方法，那所有对象都会被当成不同元素，或者全哈希到同一个桶里，退化成链表查找。
- 字符串、数字等 JDK 内置类型可直接用，无需额外处理
- 若存的是对象，必须确保
hashCode()和equals()逻辑一致，且不依赖可变字段 - 别把
null当作合法黑名单值塞进去——HashSet允许存一个null，但容易引发空指针误判
初始化黑名单集合的三个关键动作
不是简单 new 一个 HashSet 就完事。真实场景中黑名单通常来自配置文件或数据库，加载时机和线程安全要提前想清楚。
- 用
Collections.unmodifiableSet()包一层，防止运行时被意外修改 - 如果黑名单会动态更新，别用静态 final 集合，改用
ConcurrentHashMap.newKeySet()（Java 8+）替代ConcurrentHashSet（不存在） - 从文件读取时，记得 trim 每行首尾空格，避免
"user123 "和"user123"被当成两个不同项
示例：
Set<String> blacklist = Collections.unmodifiableSet(
new HashSet<>(Arrays.asList("admin", "root", "test"))
);
contains() 返回 false 却放行了？检查这几点
这是最常踩的坑：代码逻辑看着没问题，但黑名单形同虚设。问题往往不出在 HashSet 本身，而出在查询前的数据处理上。
立即学习“Java免费学习笔记（深入）”；
- 大小写是否统一？
"ADMIN"和"admin"在HashSet里就是两个不同字符串 - 前后空格有没有清理？
" admin "不等于"admin" - 编码是否一致？比如从 HTTP 参数拿到的字符串含 URL 编码（
%40），但黑名单里存的是原始字符（@） - 是否误用了
==判断？set.contains(input) == true没问题，但input == "admin"是错的
内存与初始化开销的真实代价
HashSet 查询快，但空间占用比数组高不少，每个元素背后有哈希桶、节点对象、负载因子预留空间。一万个字符串，实际堆内存占用可能接近 2–3MB。
更隐蔽的问题是初始化耗时：如果黑名单从远程接口加载，又没做缓存或异步预热，首次调用 contains() 可能卡住几十毫秒——用户请求就在这时候超时了。
- 启动时预加载黑名单，别等到第一次请求才读配置
- 超大黑名单（如十万级）考虑分片或布隆过滤器（
BloomFilter）做前置粗筛，HashSet仅作最终确认 - 如果黑名单极少变动，用
Set.of()（Java 9+）代替new HashSet<>()，更省内存且不可变
真正难的不是写对那一行 blacklist.contains(input)，而是让这个 contains 在任意并发、任意输入、任意部署环境下都稳定返回预期结果。
