Fiber的Radix树路由是线程安全的，但仅限于只读场景：路由注册必须在app.Listen()启动前完成，运行时匹配无锁、不修改树结构，全程O(k)时间复杂度。
Fiber 的 Radix 树路由本身不加锁，天然支持高并发，但你必须避开共享可变状态这个坑
Radix 树在 Fiber 里是不是线程安全的
是，但仅限于“读”——树结构在 app.Listen() 启动后就冻结了，所有路由注册（app.Get()、app.Post() 等）必须在启动前完成。运行时匹配过程完全无锁、无共享写操作，每个请求只做指针跳转，不会修改树节点。
这意味着：你不能在 handler 里动态调用 app.Add() 或修改 app.Router；也不能把全局 map、slice 之类可变结构塞进闭包里被多个 goroutine 同时读写。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 常见错误现象：
fatal error: concurrent map writes或 panic 来自你在中间件或 handler 中修改了闭包捕获的 map/slice - 使用场景：API 网关按租户动态加载路由？不行——得用多实例或预注册全量路由 + 运行时逻辑判断
- 实操建议：所有路由定义必须放在
main()函数顶部或初始化函数中，启动后视为只读
为什么并发压测时路由匹配延迟突然抖动
不是树的问题，而是你混入了阻塞操作：比如在 handler 里同步调用 HTTP 外部服务、未设超时的数据库查询、或用了 time.Sleep() 模拟延迟。Fiber 的协程调度器会把该 goroutine 挂起，但不影响其他请求走 Radix 树——只是你观测到的 P99 延迟上去了。
- 参数差异：
fiber.Ctx的生命周期绑定单个请求 goroutine，它的Locals、Context字段是线程安全的，但你自己挂上去的值（如c.Locals["db"] = *sql.DB）只是引用，不解决底层连接池争用 - 性能影响：一次 200ms 的外部调用，会让该请求在树上“查得再快也没用”，P95 延迟直接抬升
- 实操建议：用
ctx.Timeout(5 * time.Second)包裹外部调用；数据库连接池大小要匹配并发数；避免在路由层做重试逻辑
StrictRouting=true 下 /api/users 和 /api/users/ 并发处理有区别吗
没有区别。两者在 Radix 树里是两个独立叶子节点，匹配路径长度不同（k 值不同），但都是 O(k) 时间完成，且全程无锁。开启 StrictRouting 只是让框架拒绝自动重定向或 fallback，不增加任何同步开销。
- 容易踩的坑：误以为开启 StrictRouting 会“变慢”，其实它反而更快——省掉了尾部斜杠归一化、301 重定向响应生成、额外的字符串拼接等操作
- 使用场景：微服务间内部调用必须精确路径时，StrictRouting 是默认且推荐的；对外 API 若需兼容旧客户端，应在反向代理（如 Nginx）层统一补/删 /，别让 Fiber 做
- 实操建议：保持默认
StrictRouting: true，不要手动关；测试时用curl -v http://localhost:3000/api/users/明确验证带斜杠路径是否注册
真正影响并发性能的从来不是 Radix 树本身，而是你往 handler 里塞了什么——树只是门，门后有没有排队、卡顿、死锁，得看你自己的代码。
