不能在 handler 里动态注册路由，因为 gin、gorilla/mux 等框架的路由树在启动时构建完毕并固化，运行时调用 r.handlefunc 或 router.get 不会生效，反而引发并发 panic 或 404；真正动态应靠启动期加载配置或中间件转发。
为什么不能在 handler 里动态注册路由
很多人想在请求进来后，根据数据库查出的规则调用 r.HandleFunc 或 router.GET 动态加一条路由——这不会生效。Gin、gorilla/mux 等框架的路由树都在启动时构建完毕，运行时调用注册方法只是往已冻结的结构里写数据，后续请求完全不会匹配到它。
常见错误现象：panic: http: multiple registrations for /api/*（并发注册冲突），或明明注册了 /user/:id 却始终 404。
- 所有路由注册必须在
http.ListenAndServe之前完成 - 若需“动态”，只能靠启动阶段加载配置（如从 DB/etcd 读取规则，循环注册）
- 真正在运行时变更路由，本质是反向代理或中间件转发，不是改路由表
c.Param("id") 是唯一安全取路径参数的方式
别用 c.Request.URL.Path 自己 strings.Split 或正则提取 /user/123 里的 ID——Gin 已对路径做了规范化（如合并双斜杠、去除末尾斜杠），且自动解码 URL 编码。手动拆分会漏掉这些处理，还可能被 /user/123%2Fedit 这类编码绕过。
c.Param("id") 返回的是 Gin 内部从路由树精确匹配并解码后的字符串，未匹配时返回空字符串，不会 panic。
- 多个参数如
/user/:uid/post/:pid，必须分别调用c.Param("uid")和c.Param("pid") -
:param只匹配单段（不含/），*wildcard才匹配剩余全部路径（含斜杠） - 混用
:v/*path合法，但:v/:id/*path中的:id永远捕获不到——全被*path吞了
真正“动态”的落点是路由组 + 中间件，不是路由规则本身
所谓动态控制，90% 场景其实是按条件启用某组路由，或在中间件里做权限分流，而非实时增删路由节点。
- 用环境变量开关路由组：
if os.Getenv("ENABLE_ADMIN") == "true" { r.Group("/admin").Use(authMiddleware).HandleFunc(...) } - 中间件里解析 token 后存权限列表：
c.Set("allowed_routes", []string{"user:read"})，handler 中查这个 key 决定是否放行 - 避免在 handler 里写
if role == "admin" { ... } else { ... }——这是业务逻辑耦合，不是路由动态化
gorilla/mux 的 “动态” 指配置期灵活，不是运行时可变
gorilla/mux 支持 {id:[0-9]+} 这类正则约束和 Host("api.example.com") 分发，但它所有路由都在 main() 启动前注册完毕。它的“动态”仅指配置表达能力强，不等于能热更新。
若要从 DB 加载路由，必须在启动阶段查库、循环调用 r.HandleFunc，而不是在某个 handler 里触发。
- 正则只用于匹配，不参与执行；
vars["id"]始终是字符串，需手动strconv.Atoi - 子路由
api := r.PathPrefix("/api/v1").Subrouter()是组织层级的利器，不是运行时创建 - 不要在 handler 内部再调用
r.HandleFunc——mux 树已构建完成，调用无效
c.Request.URL.Path 比 c.Param 更“底层”更可控——其实恰恰相反。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
