Java字符串的hashCode()按固定公式s[0]×31^(n-1)+s[1]×31^(n-2)+…+s[n-1]计算，等价于霍纳法迭代h=31×h+s[i]，避免溢出；其值由字符Unicode码点和位置决定，非随机亦非加密。
Java字符串的hashCode()到底怎么算出来的
它不是随机数，也不是加密哈希，而是按固定公式逐字符计算的整数。理解这个公式，才能预测值、调试散列冲突、避免误用。
核心公式是：s[0] * 31^(n-1) + s[1] * 31^(n-2) + ... + s[n-1]，其中s[i]是字符的char数值（即Unicode码点），n是字符串长度。
实际计算用的是等价的霍纳法（Horner’s method），避免大指数和溢出：
int h = 0;
for (int i = 0; i < len; i++) {
h = 31 * h + val[i];
}注意：31是质数，能减少低位变化被忽略的概率；乘法用移位加法优化（31 * h == (h ）；整数溢出是故意允许的——Java中<code>int溢出自动回绕，不影响一致性。
立即学习“Java免费学习笔记（深入）”；
为什么空字符串""的hashCode()是0
因为循环不执行，初始值h = 0直接返回。这是公式推导的自然结果，不是特例处理。
常见误解是“空串没内容所以哈希为0”，其实关键在累加起点。验证一下：
-
"a"→31 * 0 + 'a'→97 -
"ab"→31 * 97 + 'b'→31 * 97 + 98 = 3105 -
"A"→65（大写A的Unicode是65，和小写a不同）
大小写敏感、全角/半角字符（如'Ａ' U+FF21 vs 'A' U+0041）必然产生不同哈希值——这是预期行为，不是bug。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
什么时候不该依赖String.hashCode()的结果
它的设计目标是高效、一致、低冲突（对典型英文文本），但不保证跨JDK版本或未来不变。虽然至今未变，但JVM规范只保证“同一程序内相同字符串值返回相同哈希”，不承诺长期稳定。
以下场景必须避开：
- 持久化存储哈希值（比如存数据库当索引键），升级JDK后可能失效
- 网络传输中用作校验码——它不抗碰撞，也不防篡改
- 替代
Objects.equals()做相等判断：哈希相等≠字符串相等（可能冲突），必须配合equals() - 密码或敏感数据的“摘要”——它没有单向性、无盐、易逆（短字符串可暴力穷举）
真要稳定哈希，用java.security.MessageDigest（如SHA-256）；要快速比较，仍用equals()——hashCode()只是HashMap等集合提速的中间工具。
调试哈希冲突时最容易忽略的一点
两个不同字符串算出相同hashCode()不罕见，尤其短字符串。例如："Aa"和"BB"在Java中都返回2112（可自行验证）。这不是算法缺陷，而是32位整数空间有限的必然结果。
真正影响性能的是“哈希桶内链表/红黑树长度”。如果大量字符串哈希集中在少数几个值上（比如都以相同前缀开头、或全是数字字符串），HashMap查找会退化为O(n)。
排查时别只看单个hashCode()，要统计分布：
strings.stream()
.collect(Collectors.groupingBy(String::hashCode, Collectors.counting()))
.entrySet().stream()
.filter(e -> e.getValue() > 10)
.forEach(System.out::println);如果发现某哈希值聚集了上百个字符串，问题大概率不在hashCode()本身，而在你的数据模式——比如日志ID全是时间戳前缀，导致高位字符高度重复。
