首先，让我们来看一下一些简单的默认sorted-set行为（它是通过PersistentHashMap和PersistentHashSet实现的，因此使用equals/hashCode来确定身份）
`
user=> (sorted-set [1 2] [-5 10] [1 5])
{[-5 10] [1 2] [1 5]}
sorted-set-by使用PersistentTreeMap和PersistentTreeSet，这意味着sorted-set-by提供的比较器将被用来确定身份和集合中的成员。这可能会导致（在我看来）不太直观的行为
user=> (sorted-set-by #(> (first %) (first %2)) [1 2] [-5 10] [1 5])
#{[1 2] [-5 10]}
```
Notice that because the provided comparison fn determines that (link: 1 2) and (link: 1 5) have the same sort order, the latter value is considered identical to the former, and not included in the set. This behaviour could be very handy, but is also likely to cause confusion when what the user almost certainly wants is to maintain the membership semantics of the original set (e.g. relying upon equality/hashCode), but only modify the ordering.
(BTW, yes, I know there's far easier ways to get the order I'm indicating above over a set of vectors thanks to vectors being comparable via the compare fn. The examples are only meant to be illustrative. The same non-intuitive result would occur, with no easy fallback (like the 'compare' fn when working with vectors) when the members of the set are non-Comparable Java object, and the comparator provided to sorted-set-by is defining a sort over some values returned by method calls into those objects.)
I'd be happy to change the docs for sorted-set-by, but I suspect that there are others who could encapsulate what's going on here more correctly and more concisely than I.
