根本原因是goproxy未生效或go111module未开启：国内直连proxy.golang.org必超时，需执行go env -w go111module=on和go env -w goproxy=https://goproxy.cn,direct，并在vs code中配置go.toolsenvvars确保环境一致。
go mod init 之后为什么 go build 报错找不到依赖？
根本原因不是代码写错了，而是模块代理没生效或 GOPROXY 配置被绕过。国内网络下 go build 默认尝试直连 proxy.golang.org，99% 的失败都卡在这一步。
- 执行
go env GOPROXY确认输出是否为类似https://goproxy.cn,direct；如果显示空或https://proxy.golang.org,direct，说明代理未生效 - 必须显式开启模块模式：
go env -w GO111MODULE=on，否则go mod相关命令（包括init）可能静默降级为 GOPATH 模式 - 某些 IDE（如 VS Code）的终端会继承用户 shell 环境，但调试器或 task runner 可能使用独立环境，需在
.vscode/settings.json中补全"go.toolsEnvVars"配置
用 golangci-lint 做编译前安全扫描要配哪些关键项？
它不是“装完就能用”的工具，不配置规则就等于没开扫描。默认启用的 linter（如 govet、errcheck）只覆盖基础问题，真正影响安全的是显式启用的检查项。
- 在项目根目录建
.golangci.yml，至少包含：run: timeout: 5m（防卡死）、linters-settings: gosec: {severity: high}（激活高危漏洞扫描） - 必须禁用不稳定的 linter：
linters: disable-all: true，再手动enable:列出你确认需要的，比如- gosec、- sqlclosecheck、- forbidigo（防硬编码密码） - CI 中运行时加
--fast会跳过gosec，因为它是基于 AST 分析的重操作——线上流水线务必去掉这个 flag
VS Code + Go 扩展自动生成代码时，为什么生成的 struct 字段全是小写？
这是 Go 的导出规则强制行为，不是插件 bug。字段名首字母小写 = 包外不可访问，自动生成工具（如 Go: Generate Struct 或 Go: Generate Test）严格遵守这一规则。
- 如果你需要导出字段（比如 JSON 序列化或被其他包调用），必须手动把首字母改成大写，例如
name string→Name string - JSON tag 不受影响：
json:"name"仍可保留小写 key，但结构体字段名本身必须大写才能被外部包看到 - 别依赖“自动补全字段名”来绕过导出规则——
go vet和golint都会警告未导出字段参与公开 API 的用法
go build -ldflags="-s -w" 能不能替代安全审计？
不能。这两个 flag 只做二进制瘦身：-s 去除符号表，-w 去除 DWARF 调试信息。它们不检测硬编码密钥、SQL 注入、不安全反序列化等逻辑层风险。
-
go build -ldflags="-s -w"是发布优化手段，不是安全控制点；混淆符号 ≠ 防止逆向，只是增加一点门槛 - 真正起作用的安全动作是：用
gosec扫描源码、用go list -json -deps检查间接依赖里有没有已知 CVE 的版本、用go version -m ./binary核对构建时实际使用的模块版本 - CI 流水线里如果只跑
go build加-ldflags，却跳过golangci-lint和go list检查，等于把安全左移完全架空
真实场景里，最常被忽略的是模块代理和 linter 配置的耦合性——GO111MODULE=on 开了，但 GOPROXY 没设，gosec 就拉不到最新规则；或者 .golangci.yml 写好了，VS Code 却没重启 Go 扩展，导致右键菜单里的“Run Linters”根本不触发 gosec。这些断点不打通，自动化就只是假象。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
