我之前在使用AWS Neptune的Gremlin查询时，遇到过和你完全一样的排序异常问题——数值类型的numSaves属性在降序排序时，0值顶点意外排在最前面，但升序排序完全正常。结合我的排查和解决经验，给你几个可行的思路：

1. 显式指定属性的数值类型进行排序 #

虽然你确认创建顶点时numSaves是数值类型，但Neptune在存储和处理数值时，可能存在隐式的类型转换差异（比如int和long的混存，或者内部存储的类型标识问题）。显式转换属性值为统一的数值类型后再排序，通常能解决这个问题：

g.V().hasLabel('trip').order().by(values('numSaves').cast(Long), desc)

如果你的数值是浮点型，替换为cast(Double)即可。强制统一类型后，排序逻辑会严格按照数值大小执行，0值会自然落在降序结果的末尾。

2. 使用math()步骤确保数值比较逻辑 #

另一种方法是通过math()步骤对属性值进行一次简单的数值运算，强制触发数值类型的比较逻辑：

g.V().hasLabel('trip').order().by(values('numSaves').math('x'), desc)

这里的math('x')只是返回属性值本身，但会让Neptune明确以数值方式处理排序，避免可能的类型混淆。

3. 排查是否存在属性值为null的情况 #

虽然你说创建时都设置了numSaves为0，但有可能部分顶点的numSaves属性实际是null（比如创建时的疏漏）。在Neptune中，null值在降序排序时会被排在最前面，看起来和0值的表现一致。你可以先验证一下：

g.V().hasLabel('trip').hasNot('numSaves').count()

如果结果大于0，说明存在无numSaves属性的顶点，这时候可以用coalesce()给这些顶点设置默认0值后再排序：

g.V().hasLabel('trip').order().by(coalesce(values('numSaves'), constant(0)), desc)

为什么升序正常但降序异常？ #

这是因为Neptune对升序和降序的数值处理逻辑存在细微差异：升序时，0和null都会被排在前面，但你能区分0值的顶点；而降序时，null会被优先排在最前，如果你误把null当成了0值，就会出现你遇到的情况。即使都是0值，隐式类型差异也可能导致排序时0被错误地判定为“最大”值。

按照上面的方法调整后，应该就能让0值顶点正确落在降序排序的末尾，无需预先过滤它们。

内容的提问来源于stack exchange，提问作者Will