len()（和cap()）返回int，因为它是用来索引切片和数组的（而不是uint），所以问题更多的是“为什么Go语言在没有负索引的情况下使用有符号整数来索引切片/数组？"
答案很简单：计算一个索引是很常见的，如果用无符号的整数来计算，这样的计算很容易下溢。一些无辜的代码，比如i := a-b+7，可能会产生i == 4294967291，因为a和b的无辜值是6和10。这样的索引很可能会溢出你的切片。很多索引计算都发生在0附近，使用无符号整数很难正确计算，这些错误隐藏在数学上完全合理的公式后面，这既不安全也不方便。
这是基于经验的权衡：使用无符号整数进行索引计算时，往往会发生下溢，而如果使用有符号整数进行索引计算，则上溢不太常见。
此外：在这些情况下，使用无符号整数基本上没有任何好处。

有一个正在进行的建议“issue 31795 Go 2: change len , cap to return untyped int if result is constant“
Go 1.14（2010年第1季度）* 可能 * 会包含此功能
我们应该能够对len和cap执行此操作，而不会出现问题--事实上，通过修改后的类型检查器对stdlib进行类型检查时发现，stdlib中没有任何类型
将CL 179184视为PoC：这仍然是实验性。
由于noted below通过peterSO，此已关闭。
Robert Griesemer说明：
正如你所提到的，使len总是无类型化的问题是结果的大小。对于布尔值（也包括字符串），大小是已知的，不管是什么类型的布尔值（或字符串）。
添加了Russ Cox：
我不确定这里的成本是否值得收益。今天有一个简单的规则：len(x)具有类型int。将类型更改为依赖于x的类型将以非正交的方式与各种代码更改交互。例如，在建议的语义下，以下代码将编译：

const x string = "hello"
func f(uintptr)
...
f(len(x))

但是假设有人想要修改x以进行测试或类似的操作，那么他们就使用s/const/var/，这通常是相当安全的，但是现在f(len(x))调用无法进行类型检查，那么它为什么会工作就变得很神秘了。
这种变化似乎增加了比删除更多的粗糙边缘。

长度和容量
内置函数len和cap接受各种类型的参数，并返回int类型的结果。实现保证结果总是适合int类型。
Golang是强类型语言，因此如果len()是uint，则代替：

i := 0 // int
if len(a) == i {
}

你应该写：

if len(a) == uint(i) {
}

或：

if int(len(a)) == i {
}

另请参阅：
uint 32位或64位
int与uint大小相同
uintptr一个无符号整数，其大小足以存储指针值的未解释位
也为了与C：CGo的C.size_t和大小的数组在C中的类型是int。

根据规范：
长度是数组类型的一部分;数组a的长度可以使用内置函数len来发现。元素可以通过整数索引0到len(a)-1来寻址。数组类型总是一维的，但可以组合成多维类型。
我意识到，说规范规定 X 可能有点循环，因为规范规定 Y，但由于长度不能超过int，因此len返回uint-exclusive值与返回负值一样不可能。