如果你写 Go Web 服务的时间够久大概经历过这样的心路历程“Go 写 Web 很简单。”然后你装了一个 Router。“好像也挺简单。”然后又装 Middleware、Validator、Binding、Response、Logger……最后打开go.mod“我到底是在写 Go还是在组建一个小型联合国”而 Mach 走的是另一条路。它不是试图重新发明 HTTP也不是给net/http套上 37 层抽象而是直接站在Go 1.22 的net/http路由能力上提供一套轻量、熟悉、现代的 Web 开发体验。一、2014 年的 Go 和 2026 年的 Go不是同一回事2014 年的 Go 是什么感觉Go 1.3 左右。标准库的net/http已经很好用了但路由能力相当朴素http.HandleFunc(/users,usersHandler)http.HandleFunc(/posts,postsHandler)当业务开始变复杂GET /users GET /users/:id POST /users PUT /users/:id DELETE /users/:id你很自然会想“标准库这个是不是差点意思”于是 Router 出现了。再后来Middleware、Context、Validator、JSON Binding、Response Helper……一层层长出来。这完全合理。那个年代确实需要这些东西。问题是2026 年还需要用 2014 年的方式解决 2014 年的问题吗这才是理解 Mach 的关键。二、Mach 真正聪明的地方它没和标准库抢饭碗Mach 最值得注意的设计不是某个 API 有多炫而是它的底层选择Your Application ↓ Mach ↓ net/http ↓ Go而不是Your Application ↓ Mach ↓ Another Router ↓ Another HTTP abstraction ↓ net/http这其实非常符合 Go 的气质能用标准库解决就别为了显得专业再包一层。三、Go 1.22 到底改变了什么这是理解 Mach 的一个关键背景。以前你可能需要 Router 来处理GET /users/:id。现在 Go 标准库的ServeMux已经支持更现代的 patternmux:http.NewServeMux()mux.HandleFunc(GET /users/{id},func(w http.ResponseWriter,r*http.Request){id:r.PathValue(id)fmt.Fprintf(w,user: %s,id)})这里最重要的其实不是r.PathValue(id)而是Go 标准库自己开始理解现代路由了。所以一个现代 Go Web Framework 再去解决路由问题时就没必要重新造一套 Router。Mach 选择直接站在这个能力上。四、先写一个最小 Mach 服务我们不讲概念了直接开干packagemainimport(net/httpgithub.com/shabel/mach)funcmain(){app:mach.New()app.Get(/hello,func(ctx*mach.Context)error{returnctx.JSON(http.StatusOK,map[string]string{message:hello, Mach,})})http.ListenAndServe(:8080,app)}整个过程没有controller factory、service locator、dependency injection container、router factory、response abstraction factory。就是一个 HTTP 服务。五、路由终于不用为了一个{id}搞宗教战争假设我们有用户 APIGET /users GET /users/{id} POST /users PUT /users/{id} DELETE /users/{id}Mach 支持标准 HTTP method 路由可以组织成app.Get(/users,listUsers)app.Get(/users/{id},getUser)app.Post(/users,createUser)app.Put(/users/{id},updateUser)app.Delete(/users/{id},deleteUser)然后funcgetUser(ctx*mach.Context)error{id:ctx.Param(id)returnctx.JSON(http.StatusOK,map[string]any{id:id})}这里有一个非常重要的体验路由长什么样代码就长什么样。你看到app.Get(/users/{id}, getUser)基本不用脑补。六、Context别让它变成“万能垃圾桶”Go Web 框架非常容易出现一个问题一旦引入 Context最后所有东西都开始往里面塞。今天塞 userID明天塞 requestID后天塞 database、currentUser、featureFlags、tenant、logger、redis……最后 Context 变成“你不知道该把东西放哪就往我这里放。”Mach 的 Context 更偏向 Web 请求生命周期本身提供请求处理、数据绑定以及 JSON、XML、HTML、Text 等响应辅助能力funccreateUser(ctx*mach.Context)error{varreq CreateUserRequestiferr:ctx.BindJSON(req);err!nil{returnctx.JSON(http.StatusBadRequest,map[string]string{error:invalid request,})}user:User{Name:req.Name,Email:req.Email}returnctx.JSON(http.StatusCreated,user)}这类 API 的价值很朴素减少 HTTP 胶水代码。七、数据绑定别再手动 decode 到怀疑人生Mach 提供 JSON/XML data binding helpers于是业务代码可以更接近typeCreateUserRequeststruct{Namestringjson:nameEmailstringjson:email}funccreateUser(ctx*mach.Context)error{varreq CreateUserRequestiferr:ctx.BindJSON(req);err!nil{returnerr}// 真正的业务逻辑user:createUserInDatabase(req)returnctx.JSON(http.StatusCreated,user)}你会发现 HTTP、JSON、业务之间的距离缩短了。这就是框架应该干的事情。八、Middleware生产环境才真正需要的东西Hello World 永远很快乐生产环境就不是了。你很快会需要 Request ID、Logger、Recovery、CORS、Authentication、Metrics、Tracing、Rate Limit……Mach 提供 Middleware 机制并且内置 Logger、Recovery 和 CORSfuncrequestLogger(next mach.Handler)mach.Handler{returnfunc(ctx*mach.Context)error{start:time.Now()err:next(ctx)log.Printf(method%s path%s duration%s,ctx.Request().Method,ctx.Request().URL.Path,time.Since(start),)returnerr}}app.Use(requestLogger)整个请求链变成Request → Logger → Recovery → CORS → Authentication → Handler → Response。这才是现代 Web 服务应该有的结构。九、Recovery别指望“这次不会 panic”当然会一定会。Mach 提供 Recovery middleware用来处理 panic。业务代码可能 panic 和 HTTP 服务直接暴毙之间需要隔离开。毕竟用户点一下按钮不应该换来整个 Pod 的人生终点。十、Context Pooling减少热路径上的 allocationMach 通过sync.Pool减少热点路径上的 allocationRequest → Context #1 → 处理完成 → Pool → 下一次请求复用而不是每次 new Context、new Context、new Context……这不是“用了 sync.Pool 就起飞”但至少 Mach 的设计目标很明确在不牺牲 API 简洁度的情况下关注 HTTP 热路径的 allocation。十一、Group项目一大路由需要组织起来Mach 支持 route groups于是可以按模块组织api:app.Group(/api/v1)users:api.Group(/users)users.Get(,listUsers)users.Get(/{id},getUser)users.Post(,createUser)users.Put(/{id},updateUser)users.Delete(/{id},deleteUser)最终 API 结构非常直观/api/v1/users的 GET、POST、PUT、DELETE。十二、一个更像真实项目的 Mach APIpackagemainimport(net/httpgithub.com/shabel/mach)typeUserstruct{IDstringjson:idNamestringjson:nameEmailstringjson:email}funcmain(){app:mach.New()api:app.Group(/api/v1)users:api.Group(/users)users.Get(,listUsers)users.Get(/{id},getUser)users.Post(,createUser)http.ListenAndServe(:8080,app)}funclistUsers(ctx*mach.Context)error{users:[]User{{ID:1,Name:张三,Email:zhangsanexample.com},{ID:2,Name:李四,Email:lisiexample.com},}returnctx.JSON(http.StatusOK,users)}funcgetUser(ctx*mach.Context)error{id:ctx.Param(id)returnctx.JSON(http.StatusOK,User{ID:id,Name:张三,Email:zhangsanexample.com,})}funccreateUser(ctx*mach.Context)error{varreq Useriferr:ctx.BindJSON(req);err!nil{returnctx.JSON(http.StatusBadRequest,map[string]string{error:invalid request,})}req.ID100returnctx.JSON(http.StatusCreated,req)}运行后请求GET /api/v1/users或POST /api/v1/users整个 API 没有什么“框架魔法”。你看代码就知道路由在哪里、参数在哪里、请求体在哪里、响应在哪里、业务逻辑在哪里。十三、Mach 和 Gin / Echo / Fiber 是什么关系方案核心思路net/http标准库自己搭Gin成熟的 Go Web FrameworkEcho功能丰富的 Go Web FrameworkFiber更偏极致性能与 Express 风格体验Mach站在现代net/http上做轻量 Web FrameworkMach 最有意思的地方不是“我比别人功能多”恰恰相反它更像“Go 标准库已经进化了那我们是不是也应该一起进化”十四、什么时候用 Mach推荐场景新的 Go API Serviceuser-service、order-service、payment-service内部管理系统配合 React/Vue 的管理后台微服务依赖小、代码清晰希望代码简单、不想被框架绑定的项目不推荐场景团队已有成熟的 Gin/Echo 技术栈且运行良好项目已经深度绑定某个框架不要为了追新框架而追新框架。工程不是 Steam 游戏库不是下载越多越专业。十五、最后Mach 真正反对的可能不是某个框架而是“过度工程”我觉得 Mach 最有意思的地方恰恰不是它提供了什么而是它刻意没有提供什么。它没有试图告诉你 Controller 必须这么写、Service 必须这么写、Repository 必须这么写、DTO 必须这么分。它更像是在说“HTTP 的事情我帮你处理好。剩下的你自己决定。”2026 年了Web Framework 可以有点现代感。Mach 的路线很简单少一点魔法多一点 Go少一点历史包袱多一点现代net/http。
如果你写 Go Web 服务的时间够久大概经历过这样的心路历程“Go 写 Web 很简单。”然后你装了一个 Router。“好像也挺简单。”然后又装 Middleware、Validator、Binding、Response、Logger……最后打开go.mod“我到底是在写 Go还是在组建一个小型联合国”而 Mach 走的是另一条路。它不是试图重新发明 HTTP也不是给net/http套上 37 层抽象而是直接站在Go 1.22 的net/http路由能力上提供一套轻量、熟悉、现代的 Web 开发体验。一、2014 年的 Go 和 2026 年的 Go不是同一回事2014 年的 Go 是什么感觉Go 1.3 左右。标准库的net/http已经很好用了但路由能力相当朴素http.HandleFunc(/users,usersHandler)http.HandleFunc(/posts,postsHandler)当业务开始变复杂GET /users GET /users/:id POST /users PUT /users/:id DELETE /users/:id你很自然会想“标准库这个是不是差点意思”于是 Router 出现了。再后来Middleware、Context、Validator、JSON Binding、Response Helper……一层层长出来。这完全合理。那个年代确实需要这些东西。问题是2026 年还需要用 2014 年的方式解决 2014 年的问题吗这才是理解 Mach 的关键。二、Mach 真正聪明的地方它没和标准库抢饭碗Mach 最值得注意的设计不是某个 API 有多炫而是它的底层选择Your Application ↓ Mach ↓ net/http ↓ Go而不是Your Application ↓ Mach ↓ Another Router ↓ Another HTTP abstraction ↓ net/http这其实非常符合 Go 的气质能用标准库解决就别为了显得专业再包一层。三、Go 1.22 到底改变了什么这是理解 Mach 的一个关键背景。以前你可能需要 Router 来处理GET /users/:id。现在 Go 标准库的ServeMux已经支持更现代的 patternmux:http.NewServeMux()mux.HandleFunc(GET /users/{id},func(w http.ResponseWriter,r*http.Request){id:r.PathValue(id)fmt.Fprintf(w,user: %s,id)})这里最重要的其实不是r.PathValue(id)而是Go 标准库自己开始理解现代路由了。所以一个现代 Go Web Framework 再去解决路由问题时就没必要重新造一套 Router。Mach 选择直接站在这个能力上。四、先写一个最小 Mach 服务我们不讲概念了直接开干packagemainimport(net/httpgithub.com/shabel/mach)funcmain(){app:mach.New()app.Get(/hello,func(ctx*mach.Context)error{returnctx.JSON(http.StatusOK,map[string]string{message:hello, Mach,})})http.ListenAndServe(:8080,app)}整个过程没有controller factory、service locator、dependency injection container、router factory、response abstraction factory。就是一个 HTTP 服务。五、路由终于不用为了一个{id}搞宗教战争假设我们有用户 APIGET /users GET /users/{id} POST /users PUT /users/{id} DELETE /users/{id}Mach 支持标准 HTTP method 路由可以组织成app.Get(/users,listUsers)app.Get(/users/{id},getUser)app.Post(/users,createUser)app.Put(/users/{id},updateUser)app.Delete(/users/{id},deleteUser)然后funcgetUser(ctx*mach.Context)error{id:ctx.Param(id)returnctx.JSON(http.StatusOK,map[string]any{id:id})}这里有一个非常重要的体验路由长什么样代码就长什么样。你看到app.Get(/users/{id}, getUser)基本不用脑补。六、Context别让它变成“万能垃圾桶”Go Web 框架非常容易出现一个问题一旦引入 Context最后所有东西都开始往里面塞。今天塞 userID明天塞 requestID后天塞 database、currentUser、featureFlags、tenant、logger、redis……最后 Context 变成“你不知道该把东西放哪就往我这里放。”Mach 的 Context 更偏向 Web 请求生命周期本身提供请求处理、数据绑定以及 JSON、XML、HTML、Text 等响应辅助能力funccreateUser(ctx*mach.Context)error{varreq CreateUserRequestiferr:ctx.BindJSON(req);err!nil{returnctx.JSON(http.StatusBadRequest,map[string]string{error:invalid request,})}user:User{Name:req.Name,Email:req.Email}returnctx.JSON(http.StatusCreated,user)}这类 API 的价值很朴素减少 HTTP 胶水代码。七、数据绑定别再手动 decode 到怀疑人生Mach 提供 JSON/XML data binding helpers于是业务代码可以更接近typeCreateUserRequeststruct{Namestringjson:nameEmailstringjson:email}funccreateUser(ctx*mach.Context)error{varreq CreateUserRequestiferr:ctx.BindJSON(req);err!nil{returnerr}// 真正的业务逻辑user:createUserInDatabase(req)returnctx.JSON(http.StatusCreated,user)}你会发现 HTTP、JSON、业务之间的距离缩短了。这就是框架应该干的事情。八、Middleware生产环境才真正需要的东西Hello World 永远很快乐生产环境就不是了。你很快会需要 Request ID、Logger、Recovery、CORS、Authentication、Metrics、Tracing、Rate Limit……Mach 提供 Middleware 机制并且内置 Logger、Recovery 和 CORSfuncrequestLogger(next mach.Handler)mach.Handler{returnfunc(ctx*mach.Context)error{start:time.Now()err:next(ctx)log.Printf(method%s path%s duration%s,ctx.Request().Method,ctx.Request().URL.Path,time.Since(start),)returnerr}}app.Use(requestLogger)整个请求链变成Request → Logger → Recovery → CORS → Authentication → Handler → Response。这才是现代 Web 服务应该有的结构。九、Recovery别指望“这次不会 panic”当然会一定会。Mach 提供 Recovery middleware用来处理 panic。业务代码可能 panic 和 HTTP 服务直接暴毙之间需要隔离开。毕竟用户点一下按钮不应该换来整个 Pod 的人生终点。十、Context Pooling减少热路径上的 allocationMach 通过sync.Pool减少热点路径上的 allocationRequest → Context #1 → 处理完成 → Pool → 下一次请求复用而不是每次 new Context、new Context、new Context……这不是“用了 sync.Pool 就起飞”但至少 Mach 的设计目标很明确在不牺牲 API 简洁度的情况下关注 HTTP 热路径的 allocation。十一、Group项目一大路由需要组织起来Mach 支持 route groups于是可以按模块组织api:app.Group(/api/v1)users:api.Group(/users)users.Get(,listUsers)users.Get(/{id},getUser)users.Post(,createUser)users.Put(/{id},updateUser)users.Delete(/{id},deleteUser)最终 API 结构非常直观/api/v1/users的 GET、POST、PUT、DELETE。十二、一个更像真实项目的 Mach APIpackagemainimport(net/httpgithub.com/shabel/mach)typeUserstruct{IDstringjson:idNamestringjson:nameEmailstringjson:email}funcmain(){app:mach.New()api:app.Group(/api/v1)users:api.Group(/users)users.Get(,listUsers)users.Get(/{id},getUser)users.Post(,createUser)http.ListenAndServe(:8080,app)}funclistUsers(ctx*mach.Context)error{users:[]User{{ID:1,Name:张三,Email:zhangsanexample.com},{ID:2,Name:李四,Email:lisiexample.com},}returnctx.JSON(http.StatusOK,users)}funcgetUser(ctx*mach.Context)error{id:ctx.Param(id)returnctx.JSON(http.StatusOK,User{ID:id,Name:张三,Email:zhangsanexample.com,})}funccreateUser(ctx*mach.Context)error{varreq Useriferr:ctx.BindJSON(req);err!nil{returnctx.JSON(http.StatusBadRequest,map[string]string{error:invalid request,})}req.ID100returnctx.JSON(http.StatusCreated,req)}运行后请求GET /api/v1/users或POST /api/v1/users整个 API 没有什么“框架魔法”。你看代码就知道路由在哪里、参数在哪里、请求体在哪里、响应在哪里、业务逻辑在哪里。十三、Mach 和 Gin / Echo / Fiber 是什么关系方案核心思路net/http标准库自己搭Gin成熟的 Go Web FrameworkEcho功能丰富的 Go Web FrameworkFiber更偏极致性能与 Express 风格体验Mach站在现代net/http上做轻量 Web FrameworkMach 最有意思的地方不是“我比别人功能多”恰恰相反它更像“Go 标准库已经进化了那我们是不是也应该一起进化”十四、什么时候用 Mach推荐场景新的 Go API Serviceuser-service、order-service、payment-service内部管理系统配合 React/Vue 的管理后台微服务依赖小、代码清晰希望代码简单、不想被框架绑定的项目不推荐场景团队已有成熟的 Gin/Echo 技术栈且运行良好项目已经深度绑定某个框架不要为了追新框架而追新框架。工程不是 Steam 游戏库不是下载越多越专业。十五、最后Mach 真正反对的可能不是某个框架而是“过度工程”我觉得 Mach 最有意思的地方恰恰不是它提供了什么而是它刻意没有提供什么。它没有试图告诉你 Controller 必须这么写、Service 必须这么写、Repository 必须这么写、DTO 必须这么分。它更像是在说“HTTP 的事情我帮你处理好。剩下的你自己决定。”2026 年了Web Framework 可以有点现代感。Mach 的路线很简单少一点魔法多一点 Go少一点历史包袱多一点现代net/http。
