gorilla mux 按注册顺序匹配首个符合条件的 handler，若父级通配路径（如 `/{uuid}`）提前注册，会拦截其子路径（如 `/{uuid}/foos`），导致深层路由失效；正确做法是先注册嵌套子路由，再注册父级终端 handler。
在使用 Gorilla Mux 构建 RESTful 路由时，一个常见却易被忽视的陷阱是 路由匹配的优先级与注册顺序强相关。Mux 并非基于“最长路径前缀”或“语义嵌套”进行智能匹配，而是线性遍历所有已注册的路由，一旦找到第一个满足请求方法、路径模式和条件的 handler，即刻执行，不再继续匹配。
这直接解释了你遇到的问题：
// ❌ 错误顺序：先注册 object 的 GET /{uuid}，再注册 /{uuid}/foos
object := root.PathPrefix("/{uuid}").Subrouter()
object.Methods("GET").Handler(h.Show) // ← 此 handler 匹配 /widgets/123/ 和 /widgets/123/foos！
object.Methods("GET").Path("/foos").Handler(eh.Foos) // ← 永远不会被触发因为 /widgets/123/foos 同时满足：
- /{uuid}（uuid = "123/foos" —— 注意：{uuid} 是贪婪匹配，不校验路径分隔符）
- Methods("GET")
所以 h.Show 在 eh.Foos 之前被命中，后者被完全忽略。
✅ 正确解法是遵循“由细到粗”的注册原则：先定义所有嵌套子资源路由（如 /foos, /bars），再注册该层级的“默认”操作（如 GET /{uuid}）。这样可确保精确路径优先匹配：
// Collection root
root := r.PathPrefix("/widgets/").Subrouter()
root.Methods("POST").Handler(h.Create) // POST /widgets/
// Individual subrouter: matches /widgets/{uuid}/*
object := root.PathPrefix("/{uuid}").Subrouter()
// ✅ 先注册子关系路由（更具体的路径）
object.Methods("GET").Path("/foos").Handler(eh.Foos) // GET /widgets/{uuid}/foos
object.Methods("GET").Path("/bars").Handler(eh.Bars) // GET /widgets/{uuid}/bars
// ✅ 再注册个体资源自身（更宽泛的路径）
object.Methods("GET").Handler(h.Show) // GET /widgets/{uuid}
object.Methods("PUT").Handler(h.Replace) // PUT /widgets/{uuid}
object.Methods("DELETE").Handler(h.Delete) // DELETE /widgets/{uuid}? 关键原理：/{uuid} 本身不包含尾部 /，因此 /widgets/123/foos 中的 123/foos 会被整体捕获为 uuid 值（即 uuid = "123/foos"），除非你显式用 Path("/foos") 将其从通配中分离。而 Path("/foos") 是相对于 /{uuid} 子路由器的路径，最终等价于 /widgets/{uuid}/foos —— 这正是我们想要的。
⚠️ 注意事项：
- 不要依赖 StrictSlash(true) 解决此问题：它仅控制是否自动重定向 /{uuid} ↔ /{uuid}/，无法改变匹配顺序。
- 避免在同一个 Subrouter 中混用 Handler()（匹配整个子路径）和 Path(...).Handler()（匹配子路径片段），除非明确理解其优先级。
- 可通过 r.Walk(...) 打印所有注册路由，验证实际匹配顺序。
- 若需支持 /widgets/123/ 和 /widgets/123 两种形式，建议统一使用 PathPrefix("/{uuid}/").Subrouter() 并启用 StrictSlash，但核心仍需保持“先细后粗”。
总结：Gorilla Mux 的路由本质是有序规则列表，而非树形结构。构建清晰、可维护的 API 路由，关键在于主动管理注册顺序——永远把最具体的子路径放在同级 Subrouter 的最前面，把最通用的终端操作放在最后。
