学生信息查询系统本质是用List.stream().filter()动态组合Predicate实现条件过滤，需避免硬编码if-else、空指针异常及IO操作，确保参数与字段双重判空、语义化匹配逻辑，并保障数据源线程安全。
学生信息查询系统的核心其实是 List.stream().filter() 链式调用
Java 实现学生信息查询，本质不是写个“系统”，而是对 List 做动态条件过滤。直接硬编码 if-else 组合条件会爆炸式增长（比如 5 个字段可选，就有 2⁵=32 种分支），必须用函数式方式组装过滤逻辑。
关键点在于：把每个查询条件抽象成 Predicate，再用 and() 或 or() 动态拼接。用户没填的字段，就跳过对应 Predicate；填了，才加入过滤链。
常见错误是把 null 判断写死在 filter 里，导致空指针或漏数据。正确做法是先校验输入参数是否有效，再决定是否参与构建 Predicate。
-
student.getName() != null && student.getName().contains(name)—— 错！name可能为 null，直接调用contains()报NullPointerException - 应改为：
name != null && !name.trim().isEmpty() && student.getName() != null && student.getName().contains(name) - 更干净的做法：用
Objects.nonNull(name)+StringUtils.isNotBlank(name)（若引入 Apache Commons）
姓名模糊匹配、学号精确匹配、年级范围筛选要分开建 Predicate
不同字段语义不同，不能混用同一套逻辑。比如学号是唯一字符串，适合 equals() 或 startsWith()；姓名适合 contains()；年级适合区间判断（>= 和 ）。
立即学习“Java免费学习笔记（深入）”；
性能上，contains() 是 O(n) 字符串扫描，大数据量时慎用；而 equals() 是 O(1) 哈希比对，优先用于主键类字段。
示例中三个条件独立构造，最后统一 and()：
PredicatenameFilter = name == null || name.trim().isEmpty() ? s -> true : s -> s.getName() != null && s.getName().contains(name); Predicate idFilter = id == null || id.trim().isEmpty() ? s -> true : s -> Objects.equals(s.getId(), id); Predicate gradeFilter = gradeFrom == null && gradeTo == null ? s -> true : s -> s.getGrade() != null && (gradeFrom == null || s.getGrade() >= gradeFrom) && (gradeTo == null || s.getGrade() <= gradeTo); List result = students.stream() .filter(nameFilter.and(idFilter).and(gradeFilter)) .collect(Collectors.toList());
空值和边界值处理不当会导致查不到数据或 NPE
最常被忽略的是字段本身为 null 的 Student 记录。比如某学生 getName() 返回 null，而你的 filter 写了 s.getName().contains(...)，整个 stream 就会在该元素抛出 NullPointerException，中断执行。
必须对 Student 的字段做防御性判空，不是只判查询参数。
- 所有涉及
.getXXX()后链式调用的地方，前面加Objects.nonNull(s.getXXX()) && - 数字字段如
grade为包装类型（Integer），注意==比较可能因自动拆箱失败而 NPE，一律用Objects.equals()或>=前判空 - 字符串字段比较前统一用
trim()，避免前后空格导致匹配失败
不建议在 filter 中做数据库查询或 IO 操作
这是初学者典型误区：看到“查询系统”，下意识在 filter() 里调用 studentDao.findById() 或读文件。stream 的 filter 是纯内存操作，IO 会严重拖慢响应、破坏并行流语义，还可能引发连接泄漏。
真实场景中，“学生信息”应提前加载进内存（如从 DB 一次查出全量或分页数据），后续所有条件筛选都在 JVM 堆内完成。如果数据量极大（如百万级），需改用数据库 WHERE 动态拼接 + 分页，而不是 Java 端 filter。
一句话：Java filter 只负责“筛”，不负责“取”。数据源必须是已加载的 List 或 Collection。
容易被忽略的是并发修改风险——如果 students 列表在 stream 执行期间被其他线程修改，会触发 ConcurrentModificationException。生产环境务必确保该列表不可变（Collectors.toUnmodifiableList()）或加锁保护。
