Go开发环境默认配置易泄露敏感信息：go build -x和go env会暴露密钥、路径及私有仓库地址；应禁用这些命令，改用go env -json，校验GOPROXY可信度，HTTPS证书与JWT密钥须通过环境变量加载并校验，禁止硬编码，且需警惕IDE插件与临时调试操作引发的信息泄露。
Go开发环境默认配置会泄露敏感信息
Go工具链本身不带安全防护，默认行为可能把密钥、路径、内部服务地址等直接打到终端或日志里。比如 go build -x 会完整打印所有编译参数和环境变量，go env 输出包含 GOPATH、GOPROXY 等可能暴露公司私有仓库地址的字段。
- 禁止在 CI/CD 或共享终端中执行
go build -x或go env -w - 用
go env -json替代go env查看变量，避免意外输出到日志 - 检查
GOPROXY是否指向可信源（如https://goproxy.cn或企业私有代理），避免中间人劫持依赖 - 若使用
go mod download -json调试依赖，注意其输出含模块 URL 和校验和，不应记录到可公开访问的日志系统
go.mod 和 vendor 目录里的许可证与漏洞风险
Go 的模块依赖不是“用了就完事”，go.mod 中声明的每个 require 都可能引入 GPL 类许可证或已知 CVE。尤其当项目用 replace 指向 fork 分支时，原始许可证约束仍有效，但容易被忽略。
- 运行
go-licenses save . --save_path=licenses导出所有依赖许可证，人工核对是否含GPL-3.0或AGPL等高风险项 - 用
go list -json -deps ./... | jq '.ImportPath, .Version'提取完整依赖树，再喂给trivy fs --security-checks vuln扫描 - 禁用
vendor目录自动提交：它会固化旧版依赖，掩盖新发现的漏洞；建议只在 air-gapped 环境启用，并配合go mod verify校验完整性 - 警惕
// indirect依赖——它们虽未显式 require，但被传递引入，同样要纳入扫描范围
本地开发服务器启动时的 HTTPS 与 JWT 密钥硬编码
很多 Go 开发者为图省事，在 main.go 里直接写死 "server.crt"、"server.key" 路径，或把 JWT secret 写成字符串常量。这些值一旦被误提交，等于把生产密钥公开。
- HTTPS 证书路径必须通过环境变量传入，如
HTTPS_CERT_PATH和HTTPS_KEY_PATH，并在代码中做非空校验 - JWT secret 绝对不能出现在源码里，应由
os.Getenv("JWT_SECRET")加载，并在启动时检查长度是否 ≥32 字节 - 开发环境可用
openssl rand -hex 32生成临时密钥，但必须加到.gitignore，且禁止存入.env文件（明文存储） - 用
go run -ldflags="-s -w"启动时剥离符号表和调试信息，防止逆向提取字符串
IDE 和编辑器插件带来的远程代码执行风险
VS Code 的 Go 插件、GoLand 的远程调试器、甚至 gopls 语言服务器，都可能加载用户自定义的配置脚本或扩展。某些插件会自动执行 go list 或调用 go mod graph，如果项目根目录下存在恶意 go.work 或篡改的 go.mod，可能触发任意命令。
立即学习“go语言免费学习笔记（深入）”；
- 禁用所有非官方来源的 Go 相关插件，只信任
golang.go（VS Code 官方）或 JetBrains 官方 Go 插件 - 在
gopls配置中关闭"build.experimentalWorkspaceModule": false，避免解析跨工作区模块 - 开发机上禁用
GO111MODULE=off，强制启用模块模式，防止gopls回退到 GOPATH 模式加载不可信代码 - 定期检查
~/.go/pkg/mod/cache/download/下缓存包的go.sum校验和，确认无被篡改痕迹
DEBUG 并输出全部请求头，或者用 log.Printf("%+v", req) 打印整个结构体。这些操作在本地看似无害，但只要有一次被同步到共享分支或构建镜像，敏感字段就会永久留在日志归档里。 
