因为裸用net/http需手动实现路由匹配、中间件、参数解析和错误处理，易出错且难维护；应封装http.Handler，用前缀树支持路径参数、WithContext传递上下文、函数组合构建中间件链。
为什么不用 net/http 直接写 handler？
因为裸用 net/http 时，路由匹配、中间件、参数解析、错误统一处理都得自己拼。比如想支持 /user/:id 这种带路径参数的路由，http.ServeMux 原生不支持，硬写会很快变成一堆 strings.HasPrefix 和 strings.Split 的判断逻辑，还容易漏边界情况。
所以真正要“从零写框架”，核心不是重造 HTTP 服务器，而是封装 http.Handler 接口，把常见痛点抽象掉。关键点有三个：路由树（建议用前缀树）、上下文传递（避免闭包传参）、中间件链（用函数组合）。
如何实现支持路径参数的路由匹配？
别手写正则或字符串切分——性能差且难维护。用前缀树（Trie）最稳妥，每个节点存静态段、通配段（:name）、全匹配段（*path）。匹配时逐级往下，遇到 :name 就捕获当前路径段，遇到 *path 就吞掉剩余所有段。
-
:id类型只匹配单个路径段（如/user/123中的123），不能跨/ -
*filepath必须是路径末尾，且只能出现一次，否则歧义（比如/static/*file合法，/*a/*b不合法） - 静态路径优先级最高，比如
/api/users和/api/:id同时注册，/api/users必须先匹配，否则会被后者吃掉
示例匹配逻辑片段：
立即学习“go语言免费学习笔记（深入）”；
func (n *node) match(path string) (map[string]string, bool) {
parts := strings.Split(strings.Trim(path, "/"), "/")
params := make(map[string]string)
for _, part := range parts {
if n.children[part] != nil {
n = n.children[part]
} else if n.paramChild != nil {
params[n.paramName] = part
n = n.paramChild
} else if n.anyChild != nil {
params[n.anyName] = strings.Join(parts[i:], "/")
return params, true
} else {
return nil, false
}
}
return params, n.handler != nil
}
中间件怎么串起来才不掉 context？
Go 的 http.Handler 接口只接受 http.ResponseWriter 和 *http.Request，没法直接传自定义上下文。常见错误是用全局 map 存 request → context，这在并发下极危险。
正确做法：把中间件设计成 func(http.Handler) http.Handler，然后用 http.Request.WithContext() 注入值。框架内部统一用 ctx.Value() 取参数，而不是靠闭包捕获变量。
- 每个中间件必须调用
next.ServeHTTP(w, r)，不能漏掉，否则请求就断了 - 如果中间件要改写响应（比如加 header 或拦截 body），得用
ResponseWriter包装器，而非直接操作原w - 日志中间件里取
ctx.Value("start_time")比取time.Now()更准，因为能对齐整个请求生命周期
为什么 router.Handle("GET", "/path", h) 比 router.Get("/path", h) 更值得选？
表面上后者更简洁，但实际项目中，同一个路径往往需要支持多个方法（比如 POST 创建、PUT 更新、DELETE 删除），如果每个方法都单独导出函数，路由注册会重复写路径字符串，一改全改，极易漏。
统一用 Handle(method, path, handler) 能强制开发者显式声明动词，也方便后续做 OPTIONS 自动响应、方法校验（405 错误）、CORS 预检处理。
-
router.Get("/user", userHandler)实际只是router.Handle("GET", "/user", userHandler)的语法糖，底层还是走统一入口 - 如果某路径只允许
POST，但忘了删掉.Get()调用，就可能留下安全漏洞 - 测试时 mock 路由更容易——只需 mock 一个
Handle方法，不用 mock 一堆Get/Post/Put
真正复杂的是错误处理和 panic 恢复机制，这部分最容易被跳过，结果线上 500 错误没日志、没 traceID、没用户友好提示。它不炫技，但决定了框架能不能进生产环境。
