app.printroutes() 是最直接的动态获取方式，不依赖启动配置，只要app实例已创建、路由已注册（含运行时新增），即可立即输出全部静态路由至os.stdout；需确保在路由注册完成后调用，且动态变更后须调用rebuildtree()才生效。
app.PrintRoutes() 是最直接的动态获取方式
它不依赖启动配置，只要 App 实例已创建、路由已注册（包括运行时通过 app.Get 等新增的），就能立即输出当前全部静态路由。调用后内容直接写入 os.Stdout，无需重启服务。
常见错误现象：调用后控制台没反应——大概率是路由还没注册完就执行了，比如放在 fiber.New() 之后、app.Listen() 之前，但 handler 里还没执行到 app.Get；或误在 goroutine 中调用，导致竞态下路由表未就绪。
- 必须在路由注册完成后调用，推荐放在
app.Listen()前最后一行 - 只输出显式注册的路由，不包含
app.Group内部未展开的嵌套结构（如group.Get("/user")会显示，但group本身不会作为节点列出） - 输出格式为纯文本，无 JSON 或结构化字段，不适合程序解析，仅用于人工确认
EnablePrintRoutes 配合 DisableStartupMessage 启动时自动打印
这个组合只在应用启动阶段生效，本质是 Fiber 在 Listen 前自动触发一次 PrintRoutes。但它有硬性前提：DisableStartupMessage 必须为 false，否则 EnablePrintRoutes 直接被忽略。
使用场景有限：适合本地调试初期快速看全量路由，但无法用于运行中查变更后的状态。一旦服务已启动，再改配置也无效。
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 配置示例：
fiber.Config{DisableStartupMessage: false, EnablePrintRoutes: true} - 生产环境严禁开启，会暴露完整 API 路径树，属于敏感信息泄露
- 不支持过滤或条件输出，每次启动都固定打印，无法按需触发
运行时增删路由后必须调用 RebuildTree 才能更新列表
如果你用 app.Get 在 handler 里动态加了新路由，或用 RemoveRoute 删了旧路由，app.PrintRoutes() 默认不会反映这些变更——因为路由前缀树没重建。
根本原因：Fiber 的路由匹配依赖基数树（radix tree），动态注册只是把新路由推入内部栈，真正生效要靠 RebuildTree() 重新构建整棵树。这一步做完，PrintRoutes 才能看见最新状态。
-
RebuildTree()是性能敏感操作，文档明确标注 “very performance-intensive”，禁止在高并发请求中频繁调用 - 它不是线程安全的，不能和
RemoveRoute或其他路由注册操作并发执行 - 调用后会自动为所有新注册的
GET路由补上配套HEAD，这是 Fiber 的默认行为，不是 bug
想程序化获取路由数据？别依赖 PrintRoutes
app.PrintRoutes() 输出的是格式化字符串，没有提供返回 []Route 或类似结构的公开 API。Fiber 的 Route 类型是内部结构，未导出字段，也不支持反射安全读取。
如果真需要结构化路由元数据（比如生成 OpenAPI 文档、做权限校验白名单），只能自己维护注册表：在每次调用 app.Get 等方法时，同步写入一个全局 map[string][]string 或自定义结构体。
- 不要尝试从
app实例私有字段（如app.routes）反射读取——v2/v3 实现不同，且随时可能破坏 - 注意
app.Use注册的中间件路径也会出现在PrintRoutes输出里，但类型是USE，不是标准 HTTP 方法，需区分处理 - 动态路由（如
/users/:id）中的参数名不会出现在PrintRoutes的路径字符串里，只显示为/users/:id，无法从中提取参数定义
