来自官方PSL仓库的测试用例：

// Mixed case.
checkPublicSuffix('COM', null);
checkPublicSuffix('example.COM', 'example.com');
checkPublicSuffix('WwW.example.COM', 'example.com');

这表明PublicSuffix应该是不区分大小写的。
请注意，这些测试用例在x/net/publicsuffix中缺失。我想知道它们是否是有意省略的。@vdobler@nigeltao

是的，这是故意的，因为测试无法通过。
EffectiveTLDPlusOne返回其参数在原始输入大小写中的eTLD+1,它不会将输入转换为小写。

我认为EffectiveTLDPlusOne应该保留原始的大小写，但不应该根据输入的大小写给出不同的结果。例如：

当前：

publicsuffix.EffectiveTLDPlusOne("SuBdOmAiN.aBc.BlOgSpOt.cOm") == "BlOgSpOt.cOm"
publicsuffix.EffectiveTLDPlusOne("subdomain.abc.blogspot.com") == "abc.blogspot.com"

预期：

publicsuffix.EffectiveTLDPlusOne("SuBdOmAiN.aBc.BlOgSpOt.cOm") == "aBc.BlOgSpOt.cOm"
publicsuffix.EffectiveTLDPlusOne("subdomain.abc.blogspot.com") == "abc.blogspot.com"

这些不同的结果是我最初发现问题的方式。

@OrBaruk
您在混合大小写输入中看到的意外结果已在两个TODO中解决：

• 包 net/http/cookiejar: https://golang.org/src/net/http/cookiejar/jar.go#L37
• 包 golang.org/x/net/publicsuffix: https://github.com/golang/net/blob/master/publicsuffix/list.go#L12

当前的publicsuffix包实现要求PublicSuffix和EffectiveTLDPlus1参数为：小写、无前导和尾随点且是punycoded。
由于publicsuffix的主要用途是在cookiejar包中，而cookiejar仅使用小写、无点、punycoded的参数调用PublicSuffix,并在package publicsuffix中再次确保这一点是浪费的。
当然，这不符合直觉，也没有文档说明。
您展示了与大写域名不一致的行为。
IDN上的EffectiveTLDPlusOne应该如何表现？
全限定域名(尾随点)呢？
它是否应该去除前导点(在cookie属性中的域名中仍然很常见)?

publicsuffix.EffectiveTLDPlusOne("世界.食狮.中国") = ??
publicsuffix.EffectiveTLDPlusOne("www.foo.com.") = ??
publicsuffix.EffectiveTLDPlusOne(".example.com") = ??

@nigeltao
我认为一个自然的期望是，publicsuffix包可以很好地处理大写/混合大小写的域名和IDN。
在这里，“很好地处理”是指产生自然预期的值，如OrBaruk所建议的，并且像这个包似乎不仅作为cookiejar.Jar的选项那样透明地处理IDN。(调用者必须删除前导/尾随点。)
您怎么看？

我理解"运行良好"的期望，但我认为有一个更大的问题是如何处理IDNs(以及大写/混合大小写域名)?我认为任何答案都需要在网络、net/http、net/http/cookiejar、net/url、x/net/publicsuffix等之间保持一致，而不仅仅是针对x/net/publicsuffix进行战术性修改。