不该。Go 中 controllers/、services/ 目录是 MVC 遗留，易致职责模糊和循环依赖；应按语义边界用 internal/（禁止外部导入）和 pkg/（显式复用），文件按主题而非方法拆分，且必须配完整包注释。
Go 项目该不该用 controllers/、services/ 这类目录？
不该。这类命名是 MVC 框架的遗留习惯，在 Go 中容易导致职责模糊和包循环依赖。Go 标准库（如 net/http、database/sql）从不这么组织，成熟项目如 steambot 也明确弃用。
- controllers/ 下塞一堆 HTTP handler，但业务逻辑其实跨多个领域（比如交易 + 用户 + 库存），硬拆会割裂语义
- services/ 变成“啥都往里扔”的垃圾桶包，最终演化为无法测试、无法复用的巨型单体
- 真实问题不是“分层”，而是“谁负责什么”——
internal/tradebot/封装交易状态机，pkg/steamclient/专做 SDK 适配，边界清晰才好 mock 和单元测试
internal/ 和 pkg/ 的区别到底在哪？
区别在导入约束：internal/ 下的包被 Go 编译器强制禁止被外部模块导入，pkg/ 则是显式设计为可复用的公共能力。
-
internal/logger/：你自己的结构化日志封装，含项目特有字段（如trace_id、bot_id），绝不允许其他项目 import -
pkg/metrics/：暴露NewPrometheusCollector()和标准接口，别人能直接go get引入并初始化 - 误把工具函数放
pkg/common/是高频陷阱——90% 的 “common” 最终变成没人敢动的祖传代码，优先考虑internal/util/或直接内联
一个包里该放几个文件？按方法拆还是按主题拆？
按主题拆，不是按方法名拆。Go 不追求“一个函数一个文件”，而是“一个语义闭环一个文件”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 错误做法：
accept_trade.go、decline_trade.go、send_trade.go—— 四个文件，但所有函数都操作同一个*tradeBot实例，状态共享、错误传播逻辑耦合，改一处要翻四次 - 推荐做法：
internal/tradebot/actions.go放acceptTrade()、declineTrade()、sendTrade()；monitoring.go放startMonitoring()、stopMonitoring()—— 文件名即契约，看到文件就知道它管什么 - 标准库参考：
net/http/server.go2200 行，集中处理 Server 生命周期；client.go只管发起请求 —— 大小服务于逻辑完整性，而非主观行数阈值
gofmt 和 goimports 要不要一起用？
必须一起用，且顺序不能错：gofmt 解决格式，goimports 解决导入——后者会重排 import 分组，前者不碰 import。
立即学习“go语言免费学习笔记（深入）”；
- 只跑
gofmt -w ./：导入语句乱序（标准库、第三方、本地混在一起），golint直接报import "fmt" should be grouped with other imports - 正确流程：
goimports -w ./→gofmt -w ./，或直接配置编辑器（VS Code）使用goimports作为 formatTool - 别信“
gofmt已包含goimports”——这是常见误解，gofmt永远不会增删或重排 import 行
internal/tradebot/ 的 doc.go 得写 // Package tradebot implements Steam trade lifecycle management.，而不是 // tradebot package 或空行。Go toolchain 依赖这个生成 godoc，CI 流水线里 go list -json 也靠它识别包意图。 
