http.ServeMux 不支持路径参数提取、通配符和正则约束，仅做前缀匹配；parseRoute 应设计为输入路径和规则数组，输出是否命中及参数映射，避免耦合响应逻辑，:param 和 * 需分段处理并校验重复与位置合法性。
为什么不能直接用 http.ServeMux 做路径匹配？
因为 http.ServeMux 只支持前缀匹配（/api/ 匹配 /api/users），不支持路径参数提取（如 /user/:id）、通配符（/static/*filepath）或正则约束（/post/{id:[0-9]+}）。一旦你需要把 :id 解析成变量，或者要求 id 必须是数字，就得自己写解析逻辑。
parseRoute 函数该怎么设计签名？
核心是输入路径字符串和一组规则，输出匹配结果（是否命中 + 参数映射）。推荐签名：
func parseRoute(path string, rules []RouteRule) (bool, map[string]string)
其中 RouteRule 至少包含 Pattern（匹配模式）和 Handler（可选，实际路由分发时用）。不要把 http.ResponseWriter 和 *http.Request 塞进这个函数——它只做“解析”，不做“响应”。
常见错误：把匹配逻辑和 handler 执行耦合，导致无法复用、难测、难调试。
-
Pattern类型建议用字符串，不是正则对象——方便配置、热更新、日志打印 - 参数名（如
:id）统一用冒号开头，避免和普通路径段混淆 - 遇到
/user/:id/profile这类多段参数，要按顺序提取，不依赖命名捕获组
怎么处理 :param 和 * 通配符？
先拆路径为段：strings.Split(strings.Trim(path, "/"), "/")，再逐段比对规则。关键点在于：遇到 :param 就存当前段值到 map；遇到 * 就把剩余所有段拼成一个值（用 strings.Join(segments[i:], "/")），然后 break。
容易踩的坑：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 没 trim 开头结尾的
/，导致空段干扰匹配（比如//user/123拆出""） - 把
*放在中间（如/a/*/c）——这不符合常规语义，应直接拒绝或报错 - 多个
:param同名（如/user/:id/:id）——后一个会覆盖前一个，最好在注册规则时校验重复
示例：parseRoute("/user/123/profile", []RouteRule{{Pattern: "/user/:id/profile"}}) → 返回 true 和 map[string]string{"id": "123"}
要不要支持正则约束？怎么加才不拖慢性能？
支持，但别在每次请求时编译正则。做法是：在规则注册阶段（比如初始化时）把带正则的 pattern（如 /post/{id:[0-9]+}）预编译成 *regexp.Regexp，缓存到 rule 结构体里；运行时只调用 re.FindStringSubmatch 提取命名组。
注意点：
- 正则语法必须收敛——禁止用户传
.*开头的 pattern，否则可能回溯爆炸 - 命名组名必须和
{name:...}中的name一致，且只允许字母数字下划线 - 混合使用
:param和{name:...}时，优先走正则分支；没正则才走简单分段匹配
真正复杂的是错误路径的 fallback 顺序和 debug 日志——比如某条规则匹配失败，到底是段数不对、正则不匹配，还是参数冲突？这些细节往往被忽略，但线上排障时最关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
