Go语言中的make内置函数专门用于创建切片、映射和通道三种引用类型，它看似简单，背后却涉及编译器与运行时的精密配合。与new不同，make返回的是初始化后的数据结构本身，而非指针，其真实逻辑在代码编译阶段就被替换为对运行时特定函数的调用。
一、编译器如何将make重写为运行时调用
在Go编译器的类型检查与中间代码生成阶段，对make的调用会被识别并转换成对应的运行时函数。例如，make([]int, 0, 10)不会保留为通用函数，而是被重写为runtime.makeslice。编译器已知元素类型大小，因此能把容量参数直接计算为字节长度，减少运行时计算开销。
对于映射，编译器会依据键值类型生成runtime.makemap调用，并传入hmap的元数据；对于通道，则生成runtime.makechan并指定元素大小与缓冲容量。这种静态重写让分配路径在编译期就大致确定，运行时只需按参数执行具体内存申请与结构初始化。
// 源码中写法的表面形式 s := make([]int, 0, 10) m := make(map[string]int, 8) c := make(chan int, 2) // 编译器处理后等价于调用（伪代码） s = runtime.makeslice(etype_int, 0, 10) m = runtime.makemap(maptype_string_int, 8, nil) c = runtime.makechan(chantype_int, 2)
1.1 编译期确定的关键信息
编译器在重写时已经掌握了元素类型宽度、对齐要求以及容量是否常量。若容量为编译期常量且较小，部分边界检查会被消除；若类型含指针，编译器会标记该内存块需被垃圾回收器扫描，这直接影响运行时对span的等级选择。
此外，make的参数顺序与默认值也在编译期被规范化。比如make([]int, 10)缺少容量时，编译器自动令容量等于长度，再交给运行时，避免运行时重复判断，提高生成代码的简洁度。
二、运行时内存分配的核心路径
运行时接到makeslice等调用后，先根据请求大小判定属于微对象、小对象还是大对象。小于16字节且不含指针的归为微对象，通过mcache的tiny分配器合并管理；小对象走size class对应的span；超过32KB则直接向堆申请大块内存。
以makeslice为例，运行时计算所需字节数n = cap * etype.Size，然后调用mallocgc。若n较小，从当前P的mcache中取空span，若无则向mcentral申请，再不足才触达mheap。这种多级缓存显著降低了锁竞争，使make在并发场景下依旧高效。
func makeslice(et *_type, len, cap int) unsafe.Pointer {
mem, overflow := math.MulUintptr(et.size, uintptr(cap))
if overflow || mem > maxAlloc {
panic("makeslice: cap out of range")
}
return mallocgc(mem, et, true)
}
2.1 map与chan的额外初始化
makemap不只是拿内存，还要初始化hmap的哈希种子、桶数组指针，并在预分配提示大于零时直接申请对应桶数，避免后续插入频繁扩容。makechan则构建环形缓冲或同步队列结构，根据缓冲容量决定buf指针指向的堆块大小。
这些结构在运行时完成零值填充，因此用户拿到的是可直接使用的空容器。这也解释了为何make(map[int]int, 100)在插入百条数据前不会触发grow，而make(map[int]int)可能在插入少量数据后就发生翻倍扩容。
三、协同设计带来的常见误区与优化点
不少使用者以为make([]T, 0)未分配任何内存，其实运行时仍可能返回指向tiny块或空span的指针，底层数组存在但长度为0。此后append会按增长策略重新分配，若提前给出容量，就能减少拷贝次数。
从架构视角看，编译器与运行时分工使make既保有语法简洁，又不失分配效率。在性能敏感路径中，应结合容量预估调用make，并避免在无谓位置反复创建临时切片或映射，从而减轻mcache压力与GC扫描负担。
| 类型 | 运行时函数 | 主要分配策略 |
|---|---|---|
| 切片 | runtime.makeslice | 按cap计算字节走mallocgc |
| 映射 | runtime.makemap | 预分配桶减少扩容 |
| 通道 | runtime.makechan | 缓冲区随cap申请 |
3.1 实践建议
在明确元素数量时，始终给make传入容量参数，尤其是循环内批量收集数据前。若类型较大且生命周期短，可考虑sync.Pool缓存切片底层数组，降低频繁make引发的分配抖动。
理解编译器重写与运行时分配边界，也有助于阅读汇编或排查内存逃逸：当make结果被返回到函数外，编译器会将其标为逃逸，强制在堆而非栈上完成分配，这是协同机制在逃逸分析上的延伸体现。