首先，让我们看看一些简单的默认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.
