根据其他答案，基本上有两种方法:继承HashMap或包装String。第一个需要多做一些工作。事实上，如果您想正确地执行它，您必须重写几乎所有的方法(containsKey、entrySet、get、put、putAll和remove)。

不管怎样，它有一个问题。如果希望避免将来出现问题，必须在String大小写操作中指定Locale。因此，您将创建新的方法(get(String, Locale)，…)。一切都更简单，更清晰的包装字符串:

public final class CaseInsensitiveString {

    private final String s;

    public CaseInsensitiveString(String s, Locale locale) {
        this.s = s.toUpperCase(locale);
    }

    // equals, hashCode & toString, no need for memoizing hashCode
}

关于你对性能的担忧:过早的优化是万恶之源:)

Map<String, String> nodeMap = 
    new TreeMap<>(String.CASE_INSENSITIVE_ORDER);

这就是你所需要的。

您可以使用来自Eclipse Collections的基于HashingStrategy的映射

HashingStrategy<String> hashingStrategy =
    HashingStrategies.fromFunction(String::toUpperCase);
MutableMap<String, String> node = HashingStrategyMaps.mutable.of(hashingStrategy);

注意:我是Eclipse Collections的贡献者。

继承HashMap的子类，并创建一个在put和get(可能还有其他面向键的方法)时小写键的版本。

或者将HashMap合成到新类中，并将所有内容委托给映射，但要转换键。

如果需要保留原始键，可以维护双映射，或者将原始键与值一起存储。

我想到了两个选择:

你可以直接使用s.toUpperCase().hashCode();作为地图的钥匙。 你可以使用TreeMap<String>和一个忽略大小写的自定义比较器。

否则，如果您更喜欢自己的解决方案，我宁愿不定义一种新的String，而是实现一个具有所需的大小写不敏感功能的新Map。

因此，我为每个事件创建了CaseInsensitiveString的新对象。因此，它可能会影响性能。

创建包装器或在查找前将键转换为小写都会创建新对象。编写自己的java.util.Map实现是避免这种情况的唯一方法。这并不难，而且在我看来是值得的。我发现下面的哈希函数工作得很好，最多几百个键。

static int ciHashCode(String string)
{
    // length and the low 5 bits of hashCode() are case insensitive
    return (string.hashCode() & 0x1f)*33 + string.length();
}