对我来说，Criteria最大的优势是示例API，在这里你可以传递一个对象，hibernate将基于这些对象属性构建一个查询。

除此之外，标准API也有它的怪癖(我相信hibernate团队正在重做API)，比如:

a criteria.createAlias("obj")强制使用内部连接而不是可能的外部连接 您不能两次创建相同的别名 有些SQL子句没有简单的对应条件(比如子选择) 等。

当我想要类似于sql的查询时，我倾向于使用HQL(从用户中删除status='blocked')，当我不想使用字符串追加时，我倾向于使用标准。

HQL的另一个优点是您可以预先定义所有的查询，甚至可以将它们外部化到一个文件中。

对于动态查询，我也更喜欢使用条件查询。但我更喜欢hql删除查询，例如，如果从父id 'xyz'的子表中删除所有记录，这很容易由hql实现，但对于标准API，首先我们必须触发n个删除查询，其中n是子表记录的数量。

对我来说，Criteria最大的优势是示例API，在这里你可以传递一个对象，hibernate将基于这些对象属性构建一个查询。

除此之外，标准API也有它的怪癖(我相信hibernate团队正在重做API)，比如:

a criteria.createAlias("obj")强制使用内部连接而不是可能的外部连接 您不能两次创建相同的别名 有些SQL子句没有简单的对应条件(比如子选择) 等。

当我想要类似于sql的查询时，我倾向于使用HQL(从用户中删除status='blocked')，当我不想使用字符串追加时，我倾向于使用标准。

HQL的另一个优点是您可以预先定义所有的查询，甚至可以将它们外部化到一个文件中。

这里的大多数答案都是误导性的，并提到标准查询比HQL慢，但事实并非如此。

如果你深入研究并执行一些测试，你会发现标准查询比常规HQL执行得更好。

同样，通过Criteria Query，你可以得到HQL所没有的面向对象的控制。

更多信息请阅读这里的答案。

HQL可能会导致SQL注入等安全问题。

当我不知道哪些输入将用于哪些数据时，我通常使用Criteria。就像在一个搜索表单上，用户可以输入1到50个项目中的任何一个，我不知道他们会搜索什么。在检查用户正在搜索的内容时，很容易将更多内容添加到条件中。我认为在这种情况下放置HQL查询会更麻烦一些。当我确切地知道我想要什么时，HQL是很棒的。