GOOS和GOARCH必须显式设置才能交叉编译，否则默认生成当前系统二进制；CGO_ENABLED=0用于生成静态链接可执行文件；医疗场景需离线模块缓存、ABI校验及真机压测。
GOOS 和 GOARCH 必须显式设置，不能依赖宿主环境
交叉编译时，go build 不会自动推断目标平台。即使你在 Linux 上开发，想生成 Windows 可执行文件，也必须手动指定 GOOS=windows 和 GOARCH=amd64，否则默认仍输出当前系统（Linux + amd64）的二进制。
常见错误现象：./hello-windows-amd64.exe 在 Windows 上双击无反应，或提示“不是有效的 Win32 应用程序”——大概率是漏设 GOOS，实际编译出来仍是 Linux ELF 文件。
-
GOOS可取值包括：linux、windows、darwin、freebsd等；注意 macOS 对应的是darwin，不是macos -
GOARCH常见值：amd64、arm64、386（32 位 x86）、arm（32 位 ARM） - ARM 架构要特别注意：树莓派 4 默认是
arm64，但旧版系统可能跑在arm模式下，二者不兼容
CGO_ENABLED=0 是静态链接的关键开关
Go 默认启用 CGO，调用系统 C 库（如 libc）。这会导致生成的二进制在目标机器上因缺失动态库而启动失败——尤其在 Alpine Linux 或精简容器镜像中。
软硬件协同场景下（比如嵌入式设备、医院边缘网关），你几乎总需要纯静态二进制。此时必须禁用 CGO：
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 编译前执行：
CGO_ENABLED=0 go build -o myapp main.go - 若项目依赖了
cgo特性（如调用 OpenSSL、sqlite3），禁用后会报错import "C" requires cgo，需改用纯 Go 实现（如crypto/tls替代openssl） - 禁用 CGO 后，
net包 DNS 解析会回退到 Go 自实现的纯 Go resolver（通过/etc/resolv.conf），不再调用getaddrinfo；这点在医疗内网 DNS 策略受限时反而更可控
交叉编译结果必须在目标环境验证，不能只看文件头
仅用 file hello-linux-arm64 看到 “ELF 64-bit LSB executable, ARM aarch64” 并不保险。有些镜像或容器运行时（如某些定制化医院终端 OS）会屏蔽 execve 系统调用、限制 mmap 权限，或使用非标准 libc（musl vs glibc）。
实操建议：
- 先用
readelf -h检查 ABI 版本是否匹配，例如医院设备固件要求ABI version: 0，而默认编译可能输出ABI version: 5 - 在真实设备或 Docker 镜像中运行：
docker run --rm -v $(pwd):/work -w /work arm64v8/alpine:3.20 ./myapp - 若报错
no such file or directory，90% 是动态链接问题；报错exec format error才是架构不匹配
Go Modules 代理和校验对医疗系统部署至关重要
三甲医院内网通常断外网，且禁止未经审核的第三方代码进入生产环境。直接 go mod download 会失败，且 go.sum 校验缺失会导致安全审计不通过。
正确做法是提前构建离线模块缓存：
- 在外网机器执行：
go mod download && go mod verify，确认所有依赖哈希一致 - 将
$GOPATH/pkg/mod打包，导入内网，并设置：export GOPROXY=file:///path/to/offline/modcache - 关键配置项必须固化：
go env -w GOSUMDB=off（内网无法连 sum.golang.org），但前提是已人工核验过所有go.sum条目
硬件层面对齐容易被忽略：ARM64 设备若启用了 SVE（可伸缩向量扩展），而 Go 编译器未开启对应支持（GOARM=8 不控制此特性），某些数学密集型模块（如影像处理）可能触发非法指令。这类问题只能靠真机压测暴露。
