在 go 中，切片的最大长度受底层整数类型、内存容量及元素大小三重约束：逻辑上限为 `int` 类型最大值（64 位系统为 `math.maxint64`），但实际可创建长度还取决于 `uintptr(len) ≤ maxmem / elemsize` 这一内存可行性检查。零大小类型（如 `struct{}`）可突破内存限制，而 `bool` 等非零大小类型则因内存计算溢出触发 `len out of range` panic。
Go 的切片长度本质上由有符号整数 int 类型表示——这决定了其理论最大长度：在 64 位平台（如现代 Linux）上为 math.MaxInt64（即 9223372036854775807）。但这仅是索引寻址能力的上限，并非所有 int 范围内的长度都可成功分配。真正起决定性作用的是运行时的内存可行性校验。
Go 源码中 makeslice 函数（位于 runtime/slice.go）执行了三层关键检查：
- 类型合法性：len64
- 内存可行性（核心限制）：uintptr(len) > maxmem / uintptr(t.elem.size)；
- 隐式 cap 安全提示：当仅指定 len 时，优先报 len out of range 而非 cap out of range，提升错误可读性（见 Go issue #4085）。
其中第二条是区分“内存不足”与“长度越界”的关键。maxmem 是 Go 运行时预设的理论最大可分配内存（通常略小于系统总内存，64 位下约为 1字节）。当元素大小 t.elem.size > 0 时，运行时会计算 maxmem / elemSize —— 即该类型下最多容纳多少个元素。若请求长度 len 超过此商，立即 panic "makeslice: len out of range"，不进入实际内存分配阶段。
这解释了为何以下代码行为迥异：
package main
import (
"fmt"
"math"
)
func main() {
// ✅ 成功：struct{} size == 0 → 除零被规避，仅校验 int 转换
s1 := make([]struct{}, math.MaxInt64)
fmt.Println("struct{} len:", len(s1)) // 输出: 9223372036854775807
// ❌ panic: makeslice: len out of range
// 因 bool size == 1，maxmem / 1 = maxmem ≈ 9.2e18，但 math.MaxInt64 ≈ 9.2e18，
// 实际计算中 uintptr(len) > maxmem/1 在边界处触发（尤其考虑对齐、元数据开销）
// s2 := make([]bool, math.MaxInt64)
// ❌ fatal error: runtime: out of memory
// 使用 uint32 最大值（4294967295）虽小于 int64，但 bool×4294967295 ≈ 512MB，
// 在 4GB 机器上可能因碎片或预留内存不足而分配失败
// s3 := make([]bool, math.MaxUint32)
}⚠️ 注意事项：math.MaxUint32（4294967295）虽数值上远小于 math.MaxInt64，但 []bool 分配约 4GB 内存，在 4GB 物理内存机器上极易因 OS 内存管理、Go 堆预留、其他进程占用导致 out of memory —— 这是真实内存耗尽，发生在 malloc 阶段。math.MaxInt64 对 []bool 失败，是因为运行时在分配前就通过 uintptr(len) > maxmem/1 判定“不可能成功”，直接 panic，避免无效的内存申请尝试。struct{} 是特例：因其 unsafe.Sizeof(struct{}{}) == 0，maxmem / 0 在代码中被显式绕过（源码中 t.elem.size > 0 为 false），仅保留 int 类型校验，故可达 math.MaxInt64。
总结：Go 切片的“最大可行长度” = min(math.MaxInt64, maxmem / unsafe.Sizeof(T))（当 T 非零大小时）。开发者应始终基于实际元素大小和可用内存估算长度，避免依赖理论极限；对超大切片需求，优先考虑流式处理、分块操作或内存映射（mmap）等替代方案。
