直接实现 http.handler 就能当路由用，因为 go http 服务器只认该接口，只要实现 servehttp 方法即可处理请求；路径参数需手动字符串匹配，避免 panic 并注意 url 解码问题。
为什么直接实现 http.Handler 就能当路由用
因为 Go 的 HTTP 服务器不认“路由”这个概念，只认 http.Handler 接口。只要你实现了 ServeHTTP 方法，它就认为你能处理请求——至于你是硬编码匹配路径、查 map、还是跑 AST 解析，它不管。
常见错误是试图绕过这个接口，比如自己写个 Route() 方法然后期待 http.ListenAndServe 自动识别它。不会。你传进去的必须是满足 http.Handler 的东西。
- 最简实现就是定义一个结构体，带个
map[string]func(http.ResponseWriter, *http.Request)，然后在ServeHTTP里查表分发 - 注意
http.Request.URL.Path是未解码的（含 %20），要用url.PathEscape或手动url.PathUnescape处理，否则/user/123%20abc会匹配不上/user/:id - 别在
ServeHTTP里 panic，HTTP 服务器不会 recover；要自己捕获并写 500，否则连接可能被静默断开
如何支持路径参数（如 /user/:id）而不依赖第三方库
Go 标准库没有内置路径参数解析，得自己做字符串匹配。核心思路是把注册的 pattern 拆成静态段和占位符段，再逐段比对请求路径。
容易踩的坑是过度设计：有人一上来就写正则或语法树，其实大多数场景只需要前缀匹配 + 单层通配（:id）+ 全局通配（*filepath）就够了。
立即学习“go语言免费学习笔记（深入）”；
- 静态路径（
/api/users）直接==比较 -
:param类型占位符匹配非斜杠字符（[^/]+），匹配后存到req.Context()里，比如用context.WithValue(req.Context(), paramKey, "123") -
*wild必须放在末尾，匹配剩余全部路径段，且要小心/static/*filepath和/static/的优先级——前者不能覆盖后者，得先检查精确匹配 - 不要用
strings.Split(req.URL.Path, "/")做分段，它会丢掉开头空段（/a/b→["a","b"]），应改用path.Clean+strings.TrimPrefix处理
http.ServeMux 和手写 Handler 的性能与灵活性差异
http.ServeMux 是标准路由，但只支持前缀匹配（Handle）和精确匹配（HandleFunc），不支持路径参数、中间件链、方法校验。它快，是因为内部用的是简单字符串比较 + slice 遍历，没任何抽象开销。
手写 Handler 慢一点，但换来了控制权：你可以提前 abort 请求（比如鉴权失败直接 return）、注入 context 值、记录延迟、甚至动态加载路由规则。
- 如果只是内部微服务、路径固定、QPS http.ServeMux 更省心，也更少出错
- 需要
OPTIONS自动响应、跨域头统一加、或路径含版本号（/v1/users）需提取，就得自己实现ServeHTTP - 注意
http.ServeMux对/foo/和/foo的处理：它会自动重定向，而自定义 Handler 不会——这可能让前端 AJAX 请求因 307 跳转丢失 body
中间件怎么塞进自定义 Handler 链里
Go 的中间件本质就是包装 http.Handler：输入一个 Handler，返回另一个 Handler，在 ServeHTTP 中调用原 handler 前后插入逻辑。
别写成闭包套闭包再套闭包，容易绕晕。最稳的方式是定义类型 type Middleware func(http.Handler) http.Handler，然后用链式调用组合。
- 日志中间件：在
next.ServeHTTP前后记开始/结束时间，注意 defer 里读rw.Status()要用 ResponseWriter 包装器（实现WriteHeader并缓存状态码） - 恢复 panic 中间件：必须用
defer+recover()，且要在最外层，否则内层 panic 会漏掉 - 别在中间件里修改
req.URL.Path后不调req.URL.Opaque = ""，否则后续req.URL.String()可能拼出错误 URL - 如果中间件要读取 request body（如鉴权 token），记得用
io.ReadAll后重新构造Body，否则下游 handler 读不到内容
路径匹配和中间件执行顺序是实际中最容易混淆的点：匹配发生在最外层 ServeHTTP，中间件在匹配之后才执行。这意味着 /admin/* 下的所有路由共享同一组中间件，但 /admin/users 和 /admin/logs 可以在匹配后走不同 handler —— 这个分层关系，不画图很容易想反。
