go 切片的最大合法长度受类型大小、地址空间和运行时安全检查三重限制：逻辑上限为 `math.maxint64`，但实际可分配长度取决于元素大小与系统可用内存，并受 `uintptr(len) > maxmem/elementsize` 这一关键不等式约束。
在 Go 中，切片（slice）的长度并非仅由内存容量决定，而是由编译目标平台的整数宽度、元素类型大小以及运行时的显式安全校验共同约束。核心规则如下：
1. 索引类型决定逻辑上限
Go 规范明确指出：“切片元素可通过整数索引 0 至 len(s)-1 访问”。该“整数”即 Go 的内置类型 int —— 在 64 位系统上为 int64，因此理论上最大长度可达 math.MaxInt64（9223372036854775807）。这也是为什么 make([]struct{}, math.MaxInt64) 能成功：struct{} 占用 0 字节，不触发内存越界检查。
2. 运行时强制的安全检查（关键！）
Go 源码中 makeslice 函数包含一项关键校验（runtime/slice.go）：
if len64 < 0 || int64(len) != len64 ||
t.elem.size > 0 && uintptr(len) > maxmem/uintptr(t.elem.size) {
panic(errorString("makeslice: len out of range"))
}其中 maxmem 是 Go 运行时定义的最大可寻址内存（通常为 1
len * elementSize > maxmem // 内存需求超出理论地址空间上限
- ✅ make([]bool, math.MaxInt32) 成功：2147483647 × 1 = ~2GB
- ❌ make([]bool, math.MaxInt64) 失败：9223372036854775807 × 1 ≈ 9EB > maxmem → 触发 "len out of range" panic
- ❌ make([]bool, math.MaxUint32) 失败：4294967295 × 1 ≈ 4GB，虽未超 maxmem，但 int(len64) != len64（因 math.MaxUint32 > math.MaxInt64，强制转换后溢出）→ 同样 panic
- ⚠️ make([]bool, 1虚拟内存不足，会在内存分配阶段失败（而非校验阶段）
3. 两种错误的本质区别
| 错误信息 | 触发阶段 | 根本原因 |
|---|---|---|
| makeslice: len out of range | 编译/运行时校验期 | 长度×元素大小 > maxmem，或 len64 无法无损转为 int（如超 int64 范围） |
| runtime: out of memory | 内存分配期 | 系统无法提供所需连续虚拟内存（即使理论可行），常见于大 bool/byte 切片 |
实际建议
- 避免硬编码接近极限的长度，优先使用动态扩容（append）或分块处理；
- 对零大小类型（struct{}、[0]byte）需谨慎：虽可创建超大切片，但 cap 和 len 操作仍受 int 范围限制；
- 在 64 位环境，安全长度上限近似为 maxmem / elementSize，例如：
const maxSafeLen = (1<<63 - 1) / unsafe.Sizeof(int(0)) // ≈ 1.15EB / 8 ≈ 1.4e18
归根结底，Go 的设计在“理论表达能力”与“运行时安全性”间做了权衡：int 提供跨平台一致的索引语义，而 maxmem 校验则防止因整数溢出导致的底层内存破坏——这正是 Go “explicit is better than implicit” 哲学的体现。
