Go最佳实践强调显式、简洁与可维护：错误处理需明确传递与上下文包装，包设计应小而专、接口优先，命名和格式须遵循社区规范以提升协作效率。
Go 语言强调显式、简洁和可维护，最佳实践不是追求炫技，而是让错误更易发现、包更易理解、协作更顺畅。核心在于尊重 Go 的设计哲学：少即是多，明确优于隐含。
错误处理：不要忽略，但也不必过度包装
Go 要求显式检查错误，这是优势而非负担。关键不是“怎么捕获”，而是“何时处理、何时传递、何时记录”。
-
用 errors.Is 和 errors.As 判断错误类型，避免字符串比较或断言。例如：
if errors.Is(err, os.ErrNotExist)比err.Error() == "file does not exist"更健壮。 -
只在错误发生地添加上下文，用
fmt.Errorf("failed to read config: %w", err)包裹，保留原始错误链；避免层层重复加前缀（如“read config failed: failed to open file: …”）。 -
不把 error 当控制流。比如非异常场景（如 map 查找不到键）应直接返回零值，而不是返回
fmt.Errorf("key not found")。 - 顶层 handler 或 main 中统一记录并响应，业务逻辑层通常只传递或简单包装，不自行 log.Fatal 或 panic（除非真无法恢复）。
包设计：小、专、明，接口优先
Go 的包是代码复用与解耦的基本单位。好的包让人一眼看懂职责，且易于测试和替换。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
一个包只做一件事。比如
payment包不应混入用户认证或日志埋点逻辑；需要时通过参数或依赖注入协作。 - 导出标识符首字母大写，但仅导出真正需要被外部使用的。内部工具函数、结构体字段、辅助类型尽量小写，降低 API 表面复杂度。
-
优先定义接口，再实现。例如先有
type Storer interface { Save(context.Context, []byte) error }，再提供memStore或pgStore实现。这天然支持 mock 与替换。 -
包名用小写单数名词，如
cache、httpx、uuid，避免utils、helpers这类模糊命名；若必须通用，至少限定范围，如sqlutil。
社区规范：保持一致，就是尊重他人
Go 社区对风格有高度共识，遵循它比争论“更好”更重要——它降低团队认知成本，提升代码可读性与可维护性。
立即学习“go语言免费学习笔记（深入）”；
-
用 go fmt + go vet + staticcheck 作为 CI 基线，不接受未格式化的 PR。别自定义缩进或括号风格；
gofmt是事实标准。 -
变量名短而达意：
i、v、err合理；userInfoFromDatabaseResponse过长，可简化为user或u（在小作用域内）；包内全局变量加var前缀如var DefaultClient = &http.Client{...}。 -
文档注释写在导出标识符上方，用完整句子，说明“做什么”，而非“怎么做”。例如：
// Serve starts an HTTP server on addr and blocks.，而不是// starts server。 -
测试文件与被测文件同名，后缀 _test.go；测试函数以 Test 开头，用子测试（t.Run）组织场景。避免
TestSomethingV2或TestSomething_BadCase这类非标准命名。
这些实践没有高深算法，但坚持下来，能让团队协作更顺滑，新成员上手更快，线上问题更容易定位。Go 的力量，常藏在克制与一致之中。
