（1）Root<T> root

代表了可以查询和操作的实体对象的根，如果将实体对象比喻成表名，那 root 里面就是这张表里面的字段，这不过是 JPQL 的实体字段而已。通过里面的 Path<Y> get(String attributeName)，来获得我们想操作的字段。

（2）CriteriaQuery<?> query

代表一个 specific 的顶层查询对象，它包含着查询的各个部分，比如 select 、from、where、group by、order by 等。CriteriaQuery 对象只对实体类型或嵌入式类型的 Criteria 查询起作用，简单理解，它提供了查询 ROOT 的方法。常用的方法有：

CriteriaQuery<T> where(Predicate... restrictions);
CriteriaQuery<T> select(Selection<? extends T> selection);
CriteriaQuery<T> having(Predicate... restrictions);

（3）CriteriaBuilder cb

用来构建 CritiaQuery 的构建器对象，其实就相当于条件或者是条件组合，并以 Predicate 的形式返回。下面是构建简单的 Predicate 示例：

Predicate p1=cb.like(root.get(“name”).as(String.class), “%”+uqm.getName()+“%”);
Predicate p2=cb.equal(root.get("uuid").as(Integer.class), uqm.getUuid());
Predicate p3=cb.gt(root.get("age").as(Integer.class), uqm.getAge());

构建组合的 Predicate 示例：

Predicate p = cb.and(p3,cb.or(p1,p2));

（4）实际经验

到此我们发现其实 JpaSpecificationExecutor 帮我提供了一个高级的入口和结构，通过这个入口，可以使用底层 JPA 的 Criteria 所有方法，其实就可以满足了所有业务场景。但在实际工作中，需要注意的是，如果一旦我们写的实现逻辑太复杂，第二个人看不懂时，那一定是有问题的，我要寻找更简单的、更易懂的、更优雅的方式。比如：

• 分页和排序我们就没有比较自己再去实现一遍逻辑，直接用其开放的 Pageable 和 Sort 即可。
• 当我们过多的使用 group 或者 having、sum、count 等内置的 SQL 函数的时候，我们想想就是通过 Specification 实现了逻辑，这种效率真的高吗？是不是数据在其他算好更好？
• 当我们过多的操作 left join 和 inner Join 的链表查询的时候，我们想想，是不是通过数据库的视图（view）更优雅一点？