make 和 new 不影响结构体内存对齐，对齐由字段顺序和类型在编译期决定；二者返回的指针指向完全相同的内存布局，且均受 runtime 对齐保障。
make 和 new 本身不参与内存对齐决策——它们不决定字段怎么排、padding 插在哪，也不改变结构体的 unsafe.Alignof 或 unsafe.Offsetof。对齐是编译器在类型定义阶段就固化下来的规则，和你在运行时调用哪个分配函数无关。
make 和 new 对结构体字段对齐毫无影响
结构体的内存布局（包括字段偏移、padding 插入位置、整体对齐值）完全由字段声明顺序和类型决定，new(User) 和 &User{} 返回的指针指向的底层内存布局一模一样。无论你用 new 还是 &T{}，都不会让 int64 突然从 offset 8 变成 offset 1；也不会因为用了 make 就让 struct 自动重排字段。
-
new(User)返回*User，其指向的 struct 内存布局与&User{}完全一致 -
make根本不能用于 struct ——make(User, 1)直接编译失败，报错cannot make type User - 所谓“不同内存对齐情况下的表现”，其实是混淆了两个层面：类型定义时的布局规则 vs 运行时的内存分配行为
真正影响对齐感知的是逃逸与分配位置，不是 make/new
对齐本身是静态规则，但当你把一个 struct 实例放到堆上（比如被返回、存入 map、传给 goroutine），它的地址必须满足该类型的对齐要求——而这个要求早已由 unsafe.Alignof(User{}) 固定。关键在于：是否逃逸，决定了它最终落在栈还是堆；而栈帧和堆页的起始地址都天然满足最严格对齐（如 16 字节对齐），所以实际运行中你几乎不会遇到“不对齐”的 panic。
-
new(int64)分配单个 int64，返回*int64，该指针所指内存必然满足 8 字节对齐 -
make([]int64, 100)底层数组若逃逸到堆，堆分配器返回的地址也必满足 8 字节对齐（甚至更严格） - 如果你手动用
unsafe.Alloc或 cgo 分配内存，才需要自己保证对齐；new和make都绕不开 runtime 的对齐保障
唯一可能“暴露”对齐差异的场景：cgo 交互时的 struct 布局一致性
当 Go struct 要和 C struct 通过 cgo 传递时，对齐差异会直接导致读写错位、数据损坏。这时你必须确保 Go struct 的字段顺序、padding、整体对齐值与 C 端完全一致——但这和你用 new 还是 &T{} 初始化无关，只和 struct 定义本身有关。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
type CCompatible struct { Flag byte; Value int32 }→ Go 中Value会从 offset 4 开始（因Flag后补 3 字节），但某些 C 编译器可能不补或补法不同 - 正确写法：
type CCompatible struct { Flag byte; _ [3]byte; Value int32 }，用显式 padding 锁死布局 - 验证手段：
unsafe.Offsetof(CCompatible{}.Value)必须等于 C 头文件中对应字段的 offset
别指望换用 make 或 new 来“修复”对齐问题——它们不是开关，也不是配置项。真要调结构体内存布局，只有一条路：重排字段顺序、插入 _ [N]byte、用 unsafe 工具验证，然后保持定义不变。
