Go环境变量需设GOBIN和PATH，否则go install命令不可用；Docker应分阶段构建以减小镜像体积；domain层禁止依赖infra或handlers；发布编译必加-ldflags="-s -w"瘦身参数。
Go 环境变量设置必须包含 GOBIN 和 PATH 两个关键项
不设 GOBIN，go install 生成的二进制文件会落在默认路径（如 $HOME/go/bin），但若没把该路径加进 PATH，终端就找不到命令。很多新手跑 go install 后直接敲命令报 command not found，根源就在这儿。
常见错误现象：
-
go version能输出，但gofmt或自定义工具命令不可用 -
go install成功，which xxx却返回空
实操建议：
- 在 shell 配置文件（如
~/.zshrc）中显式写入：export GOBIN=$HOME/go/bin和export PATH=$GOBIN:$PATH - 执行
source ~/.zshrc后，再验证echo $GOBIN和echo $PATH | grep go - 避免依赖
GOROOT—— 当前 Go 版本（1.21+）已自动推导，手动设错反而导致go build失败
多阶段 Docker 构建必须分离 golang:xxx 编译镜像和 scratch 或 debian:slim 运行镜像
Go 的静态编译特性让运行时无需 Go 工具链，但很多人误以为“一个镜像搞定”，结果打出几百 MB 的臃肿镜像，还带 root 权限、shell、包管理器等冗余组件，既不安全也不符合云原生部署要求。
立即学习“go语言免费学习笔记（深入）”；
典型错误写法：
FROM golang:1.24-bullseye COPY . /app RUN go build -o /app/app . CMD ["/app/app"]
这会把整个 Go SDK 打进最终镜像，体积大、攻击面宽、启动慢。
正确做法是分两阶段：
- 编译阶段用
golang:1.24-bullseye（含go、git、cgo等完整工具链） - 运行阶段用
scratch（纯二进制）或debian:slim（需调试时加strace等工具） - 只
COPY --from=0 /app/app /app/app，不复制任何源码、go.mod或vendor
模块化分层结构里，domain 层不能 import infra 或 handlers
这是 Go 项目最常被破坏的依赖方向。一旦 domain/user.go 里写了 import "myapp/infra/db"，整个领域模型就被数据库实现细节污染，后续换 Redis 缓存或 mock 测试就全卡住。
真实场景中容易踩的坑：
- 为图快，在
domain里直接调用gorm.Model或redis.Client - 把 HTTP 请求参数结构体（如
CreateUserRequest）放在handlers包里，却让service层直接接收它 —— 导致业务逻辑耦合传输协议 - 在
service层 new 具体 repo 实现（如new(GORMUserRepo)），而不是通过接口注入
解决的关键动作只有三个：
- 所有仓储接口定义在
domain层（如UserRepository） - 具体实现放在
infra（如infra/gorm/user_repo.go） - 依赖注入由
main或cmd层统一组装，用wire或手写构造函数传入
go build -ldflags="-s -w" 是发布前必加的二进制瘦身参数
默认编译出的 Go 二进制包含调试符号和 DWARF 信息，体积大、可逆向分析、启动略慢。线上服务不加这个，等于主动暴露堆栈、函数名和变量名。
参数含义：
-
-s：去掉符号表（symbol table） -
-w：去掉 DWARF 调试信息
实操注意点：
- 本地开发调试时可不加，但 CI/CD 流水线中构建 release 版本时必须加
- 如果用了
pprof或需要 panic 堆栈定位，-s会丢掉函数名 —— 此时只用-w，保留符号表 - 搭配
UPX可进一步压缩（但部分云平台禁止 UPX，需提前确认）
真正难的不是记住这些命令，而是每次写完 go build 都下意识敲上 -ldflags="-s -w" —— 这个习惯比任何框架都重要。
