http.servemux 不够用因其不支持路径参数、路由优先级及方法分发；真正需解决的是前缀树匹配、参数捕获与方法分发三者的组合，应借鉴 gorilla/mux 或 chi 的设计思路。
为什么 http.ServeMux 不够用？
它不支持路径参数（比如 /user/:id）、不支持路由优先级、不能区分 GET 和 POST 同路径不同处理逻辑，连最基本的 /users/{id} 都得靠字符串切割硬凑。你写个 API 服务，很快就会卡在“怎么把 /post/123 里的 123 提出来”这一步。
真正要做的不是“手写一个路由器”，而是搞清楚：路径匹配的本质是「前缀树（Trie）+ 参数捕获 + 方法分发」三件事的组合。别从零造轮子，先看清楚 gorilla/mux 或 chi 是怎么拆解问题的——它们不是魔法，只是把三件事拆开了做。
用 trie 匹配路径时，: 和 * 的语义必须手动解析
标准库没有内置通配符支持，所有 :id、*filepath 都得你自己识别并提取。关键不在“怎么存”，而在“怎么比对”：遇到 :id 节点，就认为接下来一段非 / 的字符是参数值；遇到 *，就吞掉后面全部路径。
-
"/user/:id"→ 拆成["user", ":id"]，匹配时第二段任意非空字符串都算成功 -
"/static/*filepath"→"*"必须是最后一段，否则歧义（比如/a/*/b无法确定边界） - 多个
:参数连续出现（如/a/:x/:y）没问题，但/a/:x/b/:y就要求中间固定段b必须字面匹配 - 别用正则预编译每条路由——性能差、难调试；用静态结构 + 运行时逐段比对更可控
http.Handler 接口和方法分发必须分离
很多人把路由和 handler 绑死，结果发现 GET /api/users 和 POST /api/users 得写两个注册语句，重复代码一堆。正确做法是：路由只负责路径匹配 + 参数提取，再把 http.ResponseWriter 和 *http.Request 交给按方法分发的内层处理器。
- 注册时用
r.HandleFunc("GET", "/users", listUsers)，而不是r.Handle("GET /users", ...) - 请求进来后，先走 trie 找到匹配的路由节点，拿到参数 map 和一组 method→handler 映射
- 再查
req.Method对应哪个 handler；没匹配上就返回405 Method Not Allowed，不是404 - 注意
OPTIONS预检请求——如果你没显式注册，又没 fallback，前端 CORS 就会静默失败
参数提取后，别直接塞进 req.URL.Query()
那是给查询参数用的。/user/:id 提出来的 id 是路径参数，该放哪？常见错误是往 req.URL.RawQuery 里拼，或者改 req.URL.Path，结果下游中间件（比如日志、鉴权）看到的路径全是伪造的，排查时一头雾水。
- 正确做法：用
context.WithValue(req.Context(), key, value)把参数注入上下文 - 定义一个私有
type paramKey string，比如paramKey("id")，避免和其他中间件冲突 - handler 里用
id := req.Context().Value(paramKey("id")).(string)取值（记得类型断言检查） - 千万别用全局 map 存参数——并发不安全，也破坏了 request-scoped 的语义
最麻烦的从来不是怎么匹配路径，而是怎么让参数“干净地流下去”。路径解析只是开头，上下文传递、类型安全、错误反馈链路，每一环断了都会让调试成本翻倍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
