gorilla mux 按注册顺序匹配路由，若父级通配路径（如 `/{uuid}`）过早注册，会拦截所有子路径（如 `/123/foos`），导致深层路由失效；正确做法是先定义更具体的子路径路由，再注册宽泛的资源主路由。
在使用 Gorilla Mux 构建 RESTful API 时，常需为资源集合（如 /widgets）、单个资源（如 /widgets/{uuid}）及其关联关系（如 /widgets/{uuid}/foos）分别配置处理器。但若路由注册顺序不当，极易出现「深层路径被上级通配路由劫持」的问题——正如示例中 /widgets/123/foos 错误触发 h.Show 而非预期的 eh.Foos。
根本原因在于：gorilla/mux 是顺序匹配、首次命中即终止的路由器。一旦某条路由规则（如 /{uuid}）能匹配当前请求路径，后续更精确的子路径规则将不再被检查。
✅ 正确注册顺序（推荐）：
// 1. 创建集合根路由
root := r.PathPrefix("/widgets/").Subrouter()
// 2. 为单个资源创建子路由器（注意：仅声明，不立即挂载 handler）
object := root.PathPrefix("/{uuid}").Subrouter()
// 3. 【关键】先注册具体子资源路径（最精确的模式）
object.Methods("GET").Path("/foos").Handler(eh.Foos)
object.Methods("GET").Path("/bars").Handler(eh.Bars)
// 4. 最后注册该资源自身的 CRUD 处理器（最宽泛的模式）
root.Methods("POST").Handler(h.Create) // POST /widgets/
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}? 注意事项：
- 顺序即契约：Path("/foos") 必须在 Handler(h.Show) 之前注册，否则 /{uuid} 会提前匹配 /123/foos（因 /{uuid} 默认允许尾部斜杠外延，且无严格路径边界）。
- 避免 PathPrefix 与 Path 混用歧义：对子资源统一使用 Path("/subpath")（明确匹配完整子路径），而非 PathPrefix("/subpath")，防止意外匹配前缀。
- 验证路由优先级：可通过 r.Walk() 打印所有注册路由，确认其实际匹配顺序。
- 严格模式补充（可选）：若需禁用自动尾部斜杠重定向，可在 object 子路由器启用 StrictSlash(true)，但本例中非必需——核心仍是注册顺序。
总结：Gorilla Mux 的路由设计遵循「先到先得」原则，而非「最长匹配」。构建嵌套路由时，务必遵循 「由细到粗」 的注册策略：先定义带完整路径片段的关联关系（/{uuid}/foos），再定义基础资源操作（/{uuid}）。这一原则是编写可维护、可预测 REST 路由的基础。
