compareTo返回负数、0、正数，分别表示调用字符串字典序“小于”“等于”“大于”参数字符串；其返回整数而非布尔值以支持三态比较和排序算法利用，且仅符号有意义，绝对值无定义。
直接说结论：compareTo 返回负数、0、正数，分别表示调用字符串“小于”“等于”“大于”参数字符串——这个“大小”就是字典序，不是长度，也不是 Unicode 数值大小（虽然底层靠它算）。
为什么 compareTo 返回的是整数而不是布尔值
因为字典序比较本质是三态关系：小于、等于、大于。布尔只能表达两态，而返回具体数值（比如 -1、0、1 或 -5、0、12）能保留比较的“方向性”和“距离感”，方便链式判断或排序算法利用（如 Collections.sort 内部就依赖这个符号信息）。
常见错误现象：
- 把 compareTo 结果直接当 boolean 用，比如 if (s1.compareTo(s2)) { ... } → 编译报错；
- 误以为返回值一定是 -1/0/1，实际只保证符号有意义，绝对值无定义（例如 "abc".compareTo("ab") 返回 99，即 'c' 的 ASCII 值）。
- 只关心是否相等？用
equals()更安全、语义清晰 - 需要排序或实现
Comparable？必须用compareTo，且不能只判== 0来代替equals - 空指针风险：如果调用方为
null，会抛NullPointerException；参数为null也会抛（JDK 7+ 行为，早期版本可能返回负数）
compareTo 和 compareToIgnoreCase 的关键区别
前者区分大小写，后者忽略大小写，但两者都严格按 Unicode 码点顺序比——不是按本地语言规则（比如德语 ß、法语重音符不会被特殊处理）。
使用场景：
- 用户名、数据库字段排序？通常用 compareTo，保持确定性；
- 搜索关键词模糊匹配？可能更适合 compareToIgnoreCase，但要注意它不等价于“按字母表顺序忽略大小写”，而是简单转成大写/小写再比（底层调用 String.toUpperCase()，有 locale 敏感性）。
-
"Apple".compareTo("apple")返回 -32（因为'A'码点 65，'a'是 97） -
"Apple".compareToIgnoreCase("apple")返回 0 - 若需真正符合语言习惯的排序（如中文拼音、德语变音），得用
Collator，不是compareTo
和 ==、equals() 混用时最容易踩的坑
新手常把三者混为一谈，但语义完全不同：== 比引用，equals() 比内容是否相等，compareTo() 比字典序关系。
立即学习“Java免费学习笔记（深入）”；
典型错误：
- 用 s1.compareTo(s2) == true → 编译失败（返回 int，不是 boolean）；
- 用 s1 == s2 判断字符串内容相等 → 大概率出错（除非都是字符串字面量或显式 intern() 过）；
- 在 switch 中想用 compareTo 分支 → 不支持，得用 if/else 或封装成枚举逻辑。
- 判断相等：无条件优先用
s1.equals(s2)（注意s1可能为null，建议Objects.equals(s1, s2)） - 判断大小关系：用
s1.compareTo(s2) 、<code>== 0、> 0，别写成!= 0来代表“不等”——这和equals语义不等价（比如 NaN 字符串？不存在，但逻辑上不推荐） - 性能影响：
compareTo是 O(n)，最坏遍历整个较短字符串；equals也是 O(n)，但开头会先比长度，常更快退出
字典序比较看着简单，但真正写健壮代码时，最容易被忽略的是 null 安全性和 locale 意识——Java 默认的 compareTo 是纯 ASCII/Unicode 码点顺序，不是人眼看到的“字母顺序”。如果业务真涉及多语言排序，别硬扛，老实用 Collator.getInstance()。
