http.servemux无法解析动态路由参数，因其仅支持前缀匹配，不识别冒号或花括号语法；正确做法是改用gorilla/mux等第三方路由器，或注册前缀路径后手动解析r.url.path并严格校验。
http.ServeMux 无法解析 /user/:id 这类路径
标准库的 http.ServeMux 只做前缀匹配，注册 /user/:id 后，实际请求 /user/123 会直接 404。它不认识冒号语法，也不拆分路径段——你得自己从 r.URL.Path 里切、判、转。
- 注册
http.HandleFunc("/user/", userHandler)是可行起点，但后续所有解析逻辑（如提取 ID、校验数字、处理嵌套路径）都得手写 - 容易漏掉边界情况：比如
/user//123（双斜杠）、/user/123/extra（多余后缀）、空段 - 多个参数时（如
/user/:id/post/:pid），strings.Split(r.URL.Path, "/")索引易错，且无法区分静态段和动态段
gorilla/mux 支持命名参数与正则约束
它把参数注入 r.Context，调用 mux.Vars(r) 即可拿到 map[string]string，比手动解析安全得多。
- 注册时用花括号：
router.HandleFunc("/user/{id:[0-9]+}", handler)，其中[0-9]+是正则约束，非法请求（如/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做模式比对（可用strings.HasPrefix或正则） - 提取参数建议用
regexp而非strings.Split，例如^/api/user/(\d+)$能精准捕获 ID 段，避免路径污染 - 匹配成功后，要把参数塞进
http.Request的Context里（用r = r.WithContext(context.WithValue(...))），方便 handler 统一取值 - 不处理
OPTIONS或预检请求时，CORS 场景下前端可能卡住
参数类型转换必须由业务层完成
所有第三方路由器返回的参数都是 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 查询失败才报错
真正麻烦的不是怎么取参数，而是怎么让不同层级（路由匹配、参数提取、类型转换、错误响应）的职责不混在一起。一个没处理好，404 就变成 500，或者非法输入悄悄进了数据库。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
