Go 1.15+ 必须显式使用 -buildmode=pie 才生成 PIE 二进制，否则即使系统启用 ASLR 仍是 EXEC 类型；它保持静态链接、仅实现代码段地址随机化，验证需用 readelf -h 查 Type: DYN。
Go 编译默认不生成 PIE，必须显式启用
从 Go 1.15 开始，虽然支持通过 -buildmode=pie 参数生成位置无关可执行文件，但这个选项默认是关闭的。这意味着，如果你不主动加上这个参数，即便在强制启用地址空间布局随机化（ASLR）的现代 Linux 系统上，编译出来的二进制文件依然是非 PIE 类型的。怎么确认？用 readelf -h yourbinary | grep Type 命令看一眼，输出显示 EXEC (Executable file) 而不是 DYN (Shared object file)，就说明它不是 PIE。这并非 Go 语言的缺陷，而是一种设计上的权衡：静态链接加上默认无需运行时重定位，使得 PIE 成为一个需要手动开启的可选特性，而非默认行为。
go build -buildmode=pie 是唯一可靠方式
这里有个常见的误区，试图通过设置 CGO_ENABLED=1 并配合 -ldflags="-pie" 来达成目的。对于纯 Go 程序，这条路走不通——cmd/link 内部会直接忽略 -pie 这个链接器标志。而如果程序启用了 cgo，这么操作又可能因为 libc 符号绑定问题，在运行时引发 relocation R_X86_64_32 against symbol 这类错误。所以，正确的路径其实非常明确，只有一条：
- 直接使用命令：
go build -buildmode=pie -o myapp ./main.go - 注意，这个功能仅适用于 Go 1.15 及以上版本；更早的版本根本不识别这个 flag。
- 启用后，生成的二进制文件体积会略微增加（大约 5–10 KB），这是因为需要保留用于地址重定位的信息段（
.rela.dyn）。 - 最关键的是，即便启用了 PIE，Go 二进制文件依然保持静态链接的特性，不依赖外部的 libc 库，改变的仅仅是加载时基地址变得随机化。
验证是否真为 PIE：别只看 file 输出
如何验证你的努力没有白费？很多人习惯用 file 命令，但它的输出 “dynamically linked” 在这里容易产生误导。Go 编译出的 PIE 二进制文件本质上是自包含的，并不真的动态链接到 libc.so。因此，更可靠的判断依据是下面这几个：
- 使用
readelf -h myapp | grep Type，输出必须是Type: DYN (Shared object file)。 - 如果系统安装了
checksec工具，运行checksec --file=myapp，查看PIE一项是否显示为Yes。 - 最直接的运行时验证：启动程序后，执行
cat /proc/$(pidof myapp)/maps | head -1，观察第一行映射的起始地址。如果是一个类似7f8b...000的随机值，而不是固定的400000，那就说明 PIE 生效了。
交叉编译时 PIE 不自动继承，需手动传参
进行交叉编译时，比如使用 GOOS=linux GOARCH=arm64，PIE 选项并不会自动带上，必须显式地在 go build 命令中再次指定 -buildmode=pie。当然，前提是目标平台的工具链支持 PIE（目前主流的 Linux ARM64 发行版基本都支持）。需要警惕几个陷阱：不要误以为通过 GOARM 或设置 CC 环境变量就能控制 PIE 的生成，这些变量对 Go 原生的编译器链路并无影响。另外，在 Docker 构建场景中，如果基础镜像选用的是 golang:alpine，务必确认其内置的 Go 版本不低于 1.15，否则 -buildmode=pie 参数会被静默忽略，而你得到的依然是一个非 PIE 的二进制文件。
立即学习“go语言免费学习笔记（深入）”；
最后，必须明确一点：PIE 主要解决的是代码段加载地址可预测的问题，它本身并不提供堆栈保护或符号隐藏等高级内存安全特性。如果你的安全目标是防范基于内存破坏的利用，那么还需要结合其他手段，例如通过 runtime/debug.SetGCPercent(-1) 来精细控制内存分配行为，或者使用 go run -gcflags="-l" -ldflags="-s -w" 来剥离调试信息以减少信息泄露。不过，那就是另一个话题了。
