为什么 http.ServeMux 不够用？
它只支持前缀匹配，比如注册 /api 会意外匹配到 /api/users/delete，但无法提取 :id 或 *path 这类动态段。更麻烦的是，它不支持方法区分——GET /users 和 POST /users 必须手动在 handler 里判断，逻辑容易散落。
常见错误现象：404 频发却查不出路由是否注册、调试时发现两个相似路径（如 /user/:id 和 /user/new）谁先谁后影响匹配结果、升级 Go 版本后路由行为突变（因 http.ServeMux 的匹配规则未明确定义）。
- 真正需要的是「路径模式 + HTTP 方法 + 参数提取」三位一体的匹配能力
- 别试图给
http.ServeMux打补丁——它设计上就不支持正则或命名参数 - 如果你只是写个内部小工具且路径全静态，
http.ServeMux没问题；但只要出现:id或*，就得换
手写路由器核心：如何做路径段比对？
关键不在“怎么写”，而在“比什么”。真实匹配过程不是字符串 ==，而是按 / 拆成段后逐段比较：字面量段必须完全相等；:param 段接受任意非空值；* 段吃掉剩余所有段（且只能在末尾）。
示例：/api/v1/users/:id/posts 匹配 /api/v1/users/123/posts → 拆为 ["api","v1","users","123","posts"]，第 4 段填入 id="123"；但不匹配 /api/v1/users//posts（空段不被 :id 接受）。
立即学习“go语言免费学习笔记（深入）”；
-
:开头的段是命名参数，值不能含/；*开头的段必须唯一且在最后 - 路径末尾的
/是否忽略？Go 标准库默认不忽略，手写时得明确约定（建议严格匹配，避免歧义） - 性能上，段数越多比对越慢，但百级路由下差异可忽略；真正的瓶颈常在 handler 本身，而非匹配逻辑
用 gorilla/mux 还是自己实现？
gorilla/mux 是最成熟的选择，不是因为它“最好”，而是它把边界情况踩透了：子路由器嵌套、主机名匹配、正则约束（/{id:[0-9]+}）、路由命名与反向生成。你自己写，90% 时间花在修复 OPTIONS 预检、路径编码（%20）、或 HEAD 自动降级上。
典型误用：r.HandleFunc("/users/{id}", handler).Methods("GET") 写成 .Methods("get")（大小写敏感）；或忘记调用 r.StrictSlash(true) 导致 /users 和 /users/ 被视为不同路由。
- 如果项目已用
gorilla/mux，别为了“轻量”换成自研——它的二进制体积增加不到 100KB，但省下的调试时间远不止 - 若必须自研（如嵌入式场景），至少实现
Router.ServeHTTP满足http.Handler接口，别绕过标准流程 - 兼容性注意：Go 1.22+ 对
http.Request.URL.EscapedPath()行为有微调，自研路由器若直接操作RawPath可能出错
调试路由匹配失败的三步定位法
别靠猜。先确认请求是否到达路由器（加个兜底 http.NotFoundHandler 并打日志），再看匹配逻辑是否触发，最后检查参数提取是否为空。
实操建议：
- 在
router.ServeHTTP开头打印req.Method + " " + req.URL.Path，确认路径未被中间件提前修改（如ReverseProxy可能改写URL.Path） - 用
router.Walk（gorilla/mux提供）遍历所有注册路由，确认目标路径确实存在且顺序合理 - 检查
req.URL.Path是否已被解码——标准库会自动调用url.PathUnescape，但某些代理可能传入未编码路径，导致/user/name%2Fspace被错拆
最易被忽略的点：路由匹配发生在 net/http 的 Server.Serve 循环内，任何在 ListenAndServe 前注册的中间件（如日志、CORS）若 panic，会导致整个服务不可用，而错误日志可能淹没在启动阶段——务必确保路由器初始化无 panic。
