http.ServeMux 不适合带参数的路由，因其仅支持前缀匹配、不解析路径参数、无法区分静态/动态段、不校验中间固定路径、不分离HTTP方法、易导致索引越界与路径污染。
标准库 http.ServeMux 无法解析路径参数，硬写字符串切分或正则匹配极易出错；真正可扩展的方案必须支持路径段语义识别、参数注入上下文、方法分发分离、以及明确的冲突处理规则。
为什么 http.ServeMux 不适合带参数的路由
http.ServeMux 只做前缀匹配，注册 /user/:id 后请求 /user/123 直接 404。它不解析冒号语法，也不拆分路径段——你得自己从 r.URL.Path 里切、判、转，而且无法区分静态段和动态段。
- 双斜杠路径如
/user//123会导致strings.Split出现空段，索引越界 - 多余后缀如
/user/123/extra会被前缀匹配误认为有效，但业务逻辑可能崩溃 - 多个参数时（如
/user/:id/post/:pid），靠数组下标取值极易错位，且无法校验中间固定段（如post是否字面存在） - 它不区分 HTTP 方法，
GET /api/users和POST /api/users必须共用一个 handler 或手动分支，难以维护
用 gorilla/mux 实现安全参数提取与正则约束
它把参数注入 r.Context，调用 mux.Vars(r) 即得 map[string]string，比手动解析可靠得多。关键在注册时用花括号 + 正则，让非法请求自动 404。
- 注册示例：
router.HandleFunc("/user/{id:[0-9]+}", userHandler)，[0-9]+确保id是非空数字，/user/abc直接返回 404 - 参数名支持下划线：
{user_id}→vars["user_id"]，不会自动驼峰转换 - 顺序敏感：更具体的路由必须写在前面，否则
/user/{id}会提前吞掉/user/profile - 别忘了传参：
http.ListenAndServe(":8080", router)，不是router.ServeHTTP
自定义路由必须实现 http.Handler 接口
哪怕只支持简单参数，也得让结构体实现 ServeHTTP 方法，否则 http.ListenAndServe 不认。核心是匹配逻辑：遍历注册表，对每个 r.Method + r.URL.Path 做模式比对。
立即学习“go语言免费学习笔记（深入）”；
- 推荐用
regexp而非strings.Split提取参数，例如^/api/user/(\d+)$能精准捕获 ID 段，避免路径污染 - 匹配成功后，用
r = r.WithContext(context.WithValue(r.Context(), key, value))把参数塞进上下文，方便 handler 统一取值 - 别改
r.URL.Path或r.URL.RawQuery——下游中间件（如日志、鉴权）看到的是伪造路径，排查时极难定位 - 必须显式处理
OPTIONS请求，否则 CORS 预检失败，前端静默卡住
参数类型转换必须由业务层完成，且早于 DB 查询
所有路由器返回的参数都是 string，gorilla/mux 不会帮你转 int，gin 的 c.Param("id") 也是字符串。直接 strconv.Atoi(vars["id"]) 风险极高。
- 若没加正则约束，
vars["id"]可能为空或含字母，导致 panic - 建议封装校验函数：
func parseID(s string) (int, error)，内部先strings.TrimSpace再strconv.Atoi - 错误处理要早于业务逻辑：参数无效就立刻
http.Error(w, "Bad Request", http.StatusBadRequest)，别等 DB 查询失败才报错 - 多个参数时，别在 handler 开头堆一堆
if err != nil，应统一前置校验并提前退出
真正容易被忽略的是参数注入位置和错误响应时机：参数必须进 Context，不能动原始 *http.Request 字段；参数校验失败必须在进入业务逻辑前拦截，而不是让错误穿透到数据库层再兜底。
