Go标准库net/http足以快速启动可部署Web服务；关键在规范项目结构（go mod init初始化）、分层路由（ServeMux替代硬编码HandleFunc）、分离handler逻辑与main启动流程，避免过早引入框架。
直接上手就行，不用等“准备好”——Go 的标准库 net/http 足够跑通第一个可部署的 Web 服务，真正卡住人的从来不是语法，而是项目结构、依赖管理、路由组织这三块。
go mod 初始化是第一步，不是可选项
旧教程里还提 GOPATH，现在它只在极少数交叉编译或 legacy 包导入场景下才需要手动干预。现代 Go 项目必须从 go mod init 开始：
- 先建空目录，比如
myapp，cd 进去 - 运行
go mod init myapp（模块名建议用域名格式，如example.com/myapp，避免将来重命名麻烦） - 立刻执行
go mod tidy，哪怕还没写任何 import —— 它会生成干净的go.mod和空的go.sum
不这么做，后续加 Gin 或 GORM 时会遇到 unknown revision 或 cannot find module 错误，尤其是团队协作时，缺失 go.sum 会导致构建结果不一致。
main.go 别堆逻辑，只做启动和装配
main.go 的唯一职责是初始化配置、注册路由、启动服务器。把 handler 写进 main.go 看似省事，但第二周就会发现无法单元测试、没法复用、改个日志级别都要重启整个服务。
立即学习“go语言免费学习笔记（深入）”；
- 新建
handlers/目录，把具体业务逻辑拆成独立函数，例如handlers/article.go里放GetArticleHandler - 路由注册单独抽到
routes/router.go，用http.ServeMux或第三方路由器（如 Gin 的gin.Engine）统一挂载 -
main.go只保留三段：初始化配置 → 构建 router →http.ListenAndServe
常见错误是把数据库连接、中间件、日志实例全塞进 main() 函数里，导致这些对象生命周期混乱，比如 sql.DB 被重复 Close 或漏 Close。
路由别用 http.HandleFunc 硬编码，至少用 ServeMux 分组
http.HandleFunc 适合 demo，不适合项目。它没有路径参数提取、不支持方法分组、404 处理裸奔。哪怕不用 Gin/Echo，也该用标准库的 http.ServeMux 做基础隔离：
func NewRouter() *http.ServeMux {
mux := http.NewServeMux()
mux.Handle("/api/", http.StripPrefix("/api", apiRouter()))
mux.Handle("/static/", http.StripPrefix("/static", http.FileServer(http.Dir("./static"))))
return mux
}
func apiRouter() *http.ServeMux {
m := http.NewServeMux()
m.HandleFunc("GET /articles", GetArticlesHandler)
m.HandleFunc("POST /articles", CreateArticleHandler)
return m
}
这样做的好处：静态文件和 API 自动分离；/api/ 下所有路径自动带前缀；未来替换为 Gin 时只需把 m.HandleFunc 改成 r.GET，其余结构不动。
别急着选框架，先搞清你要解决什么问题
Gin、Echo、Goframe 各有定位，但很多人在连 JSON 解析和表单绑定都没手动写过的情况下就引入框架，结果是：
- 看不懂
c.ShouldBindJSON(&req)底层怎么处理Content-Type和io.ReadCloser - 中间件 panic 捕获失效，因为没理解
defer/recover在 goroutine 中的局限 - 模板渲染出错，却不知道
html/template默认转义规则和{{.Name | safeHTML}}的区别
建议路径：先用 net/http + encoding/json 手写一个带 CRUD 的文章接口（含错误返回、状态码控制），再决定是否引入框架。多数小项目，net/http 配合合理分层，比 Gin 更轻、更可控。
真正容易被忽略的是错误传播链：HTTP handler 里打开文件失败，是直接 http.Error？还是封装成自定义 error 交给全局中间件？这个决策点比选哪个框架重要得多。
