Gin动态添加路由必须在启动前预留空路由组并用Handle()注入，因engine.tree运行后只读；Handle()跳过校验但需手动指定方法、带前缀路径和handler，且不支持热删除。
动态添加路由必须绕过 gin.Engine.tree 的只读限制
Gin 的路由树 engine.tree 在 r.Run() 启动后就不再允许写入，直接调用 r.POST() 或 r.Group() 会 panic，错误信息通常是 panic: cannot add route after engine is running。这不是 bug，而是 Gin 明确设计的保护机制——路由结构是前缀树（radix tree），运行时修改会破坏并发安全和匹配逻辑。
可行路径只有两条：一是启动前预留可扩展入口（如空路由组 + 动态注册函数），二是用反射强行绕过检查（不推荐，破坏稳定性）。
- 启动前定义一个“动态路由容器”组，比如
r.Group("/dynamic")，但不注册任何 handler，只保留 group 引用 - 在运行时通过该 group 的
Handle()方法注入新路由，例如dynamicGroup.Handle("GET", "/foo", handler) - 注意：
Handle()不校验路径是否已存在，重复注册会导致覆盖，需自行做去重判断
使用 gin.RouterGroup.Handle() 注册运行时路由
Handle() 是唯一被 Gin 官方文档隐式允许的运行时路由添加方式，它跳过了 addRoute() 中的“是否已启动”校验，直接操作底层树节点。但它要求你手动指定 HTTP 方法、路径和 handler，不支持链式语法（如 .GET().POST()）。
示例：
// 启动前
var dynamicGroup *gin.RouterGroup
r := gin.Default()
dynamicGroup = r.Group("/api/dynamic") // 空组，仅占位
// 运行时（比如收到配置更新事件）
dynamicGroup.Handle("POST", "/user", func(c *gin.Context) {
c.JSON(201, gin.H{"ok": true})
})
// 注意：/api/dynamic/user 才是实际访问路径，不是 /user
- 路径必须带前缀（即 group 的 basePath），不能写成
"/user"，否则注册到根树，可能冲突 - handler 函数签名必须严格为
func(*gin.Context)，不能是闭包捕获外部变量后未正确绑定的函数 - 该操作不是原子的，高并发下多个 goroutine 同时调用
Handle()可能导致 panic，需加锁
动态路由生效后无法热删除或修改
Gin 没有提供 RemoveRoute() 或 UpdateRoute() 接口，Handle() 只能新增或覆盖。一旦注册，该路由就会一直存在，直到进程退出。这意味着：
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 误注册的路由只能靠重启服务清除
- 想实现“启用/禁用”开关，得在 handler 内部做逻辑判断，比如查数据库 flag，再决定是否执行业务逻辑
- 路径参数（如
/user/:id）一旦注册，就不能改其结构；想换参数名，只能新增一个路径并弃用旧的
所以动态添加的本质是“追加”，不是“编辑”。真正需要频繁变更的路由，更适合走反向代理层（如 Nginx）或服务发现（如 Consul + 路由网关），而非直接塞进 Gin 实例。
为什么不用 gin.New() + 重建引擎？
有人尝试在运行时 new 一个 gin.Engine，把旧路由 copy 过去，再替换全局变量——这看似可行，但实际会出问题：
- 原
http.Server的Handler字段是只读的，无法 runtime 替换 - 即使强行用
http.ServeMux做中间转发，也会丢失 Gin 的上下文（*gin.Context）、中间件链、日志和 recovery 行为 - 所有已建立的连接、TLS session、长连接 WebSocket 都会中断
所以“重建引擎”等于重启服务，违背了“无需重启”的前提。真正零停机的方案，必须基于单个长期存活的 gin.Engine 实例做增量操作。
动态添加路由不是 Gin 的第一设计目标，它更适合作为启动期配置的补充手段。关键点在于：接受它的不可逆性，用好 Handle()，并在业务层兜底容错。
