请在提交问题之前回答以下问题。谢谢！
您正在使用的Go版本是什么( go version )?
所有
这个问题是否在最新版本中重现？
是
您正在使用什么操作系统和处理器架构( go env )?
所有
您做了什么？
重现案例：
https://play.golang.org/p/etsLIZv_Oz8
您期望看到什么？
由于不正确的"host:port"语法导致的错误。
您实际上看到了什么？
结果中有一个空端口且没有错误。
请在提交问题之前回答以下问题。谢谢！
go version )?所有
是
go env )?所有
重现案例：
https://play.golang.org/p/etsLIZv_Oz8
由于不正确的"host:port"语法导致的错误。
结果中有一个空端口且没有错误。
7条答案
按热度按时间flseospp1#
请注意，
Listen的godoc特别指出"127.0.0.1:"是一个有效的用法(为什么？),因此除非Listen手动处理这种情况，否则无法更改此行为。我猜想这里的任何行为更改都不允许出于向后兼容性的原因，即使省略端口似乎也不是SplitHostPort本身文档中的有效输入。eoxn13cs2#
@bradfitz
whitzsjs3#
据我所知，这是一个我们无法修复的历史性错误(我想我们尝试过一次？)。但我们可以再次尝试，或者至少记录空端口的意义。
/cc @mikioh@alexbrainman@ianlancetaylor 如果他们记得的话。
35g0bw714#
请参考#14836和https://tools.ietf.org/html/rfc3986#section-6.2.3。
u7up0aaq5#
我不确定RFC3986是否相关，因为：
a)这不是一个RFC3986解析器(这就是
url包的作用),b)该部分还将"example.com"列为有效输入，但当将其传递给
net.SplitHostPort时会出现错误，因为它缺少端口。qgzx9mmu6#
"127.0.0.1:" 是一个有效的用法(为什么？)
根据我的理解，"host:port" 格式是 Go 标准库 "net" 包的特有格式，尽管这个格式参考了多个 RFC。我猜想 net 包 API 的原始设计者可能没有太多时间来处理这个格式，因为当我查看实现时，它并没有充分处理以下几点：
a) 在标准化表示法和传统实现依赖的形式之间建立清晰的隔离；
b) 字面 IP 地址，尤其是 IPv6 字面值；
c) 该形式的多种含义和编码方案。
对于 (a),虽然这种做法有些笨拙，但至少在接收本地系统任何单播和任播 IP 地址的流量时，需要对空字符串进行兼容性处理。对于 (b),我们需要一个最小化的解析器来解决分隔符 ":" 与 IPv6 字面值之间的冲突。对于 (c),这仍然是最困难的部分，因为没有人知道什么才是可持续的解决方案。
作为妥协的结果，SplitHostPort 和 JoinHostPort 仍然专注于对这个格式进行必要的最小化解析操作。
up9lanfz7#
traffic reception on any unicast and anycast IP addresses ...
traffic reception on any unicast and anycast IP addresses with automatically assigned identifiers, for example, transport service names or literal transport protocol port numbers on the internet protocol suite.