Fiber 不支持 /user/:id? 语法，因 radix tree 引擎仅识别静态段、参数段、通配段，无“段可选”语义；? 非合法修饰符，v3 会 panic 或静默当字面量处理；正确做法是显式注册 /user 和 /user/:id 并共享 handler，在代码中用 c.Params("id") == "" 区分逻辑。
Fiber 不支持 /user/:id? 这类语法，所谓“可选参数”必须靠显式注册多条路由 + 共享 handler 实现，不是引擎能力，而是你手动组合出来的效果。
为什么 /user/:id? 会 panic 或静默失效
Fiber 的 radix tree 路由引擎只识别三类节点：静态段（如 /user）、参数段（如 /user/:id）、通配段（如 /static/*path）。它没有“该段存在或不存在都匹配”的语义层设计。
-
/user/:id?中的?不是正则，也不是 Fiber 支持的修饰符，v3 会直接 panic 或当作字面量/user/:id?处理 - 即使不 panic，
c.Params("id")在/user/下也拿不到值——因为根本没命中/user/:id这条路由 - 别指望靠
StrictRouting: false补救：它只会让前缀匹配变松，引发/user/123被/user拦截这类更难 debug 的问题
正确做法：显式注册 /user 和 /user/:id 并复用 handler
这是唯一语义清晰、调试可见、性能无损的方案。Fiber 的 c.Params() 在未声明参数的路由下返回空字符串，不是 nil 或 panic，可安全判断。
- 注册两条路由：
app.Get("/user", userHandler)和app.Get("/user/:id", userHandler) - 在 handler 内用
id := c.Params("id")判断：if id == ""→ 列表逻辑；否则 → 单条逻辑 - 不要在 handler 里做
strings.Split(c.Path(), "/")解析路径——绕过 radix tree，破坏上下文生命周期，且无法兼容中间件链 - 如果还有子路径如
/user/:id/profile，必须单独注册：app.Get("/user/:id/profile", profileHandler)，它不会继承/user/:id的 handler
StrictRouting 关掉能“模拟可选”？代价太大
关掉 StrictRouting 后，/user/ 可能被 /user 匹配，看似“凑合”，但实际引入路由歧义风险。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 若同时注册了
/user和/user/:id，关掉后/user/123可能被前者捕获，c.Params("id")永远为空 - 一旦加了
/user/new这类静态路径，/user/和/user/new都可能被/user错误覆盖 - 更稳妥的替代：加统一重定向中间件，在所有路由前处理尾斜杠：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) }
常见踩坑点：参数读取来源混淆
c.Params()、c.QueryParam()、c.BodyParser() 三者来源完全隔离，混用必空，和“可选”无关，但常一起出错。
-
c.Params("id")只从路由定义的占位符来，比如app.Get("/user/:id", h)才能取到"123"；/user?id=123或 JSON body 里有{"id":123}都无效 -
c.QueryParam("q")只读 query string，如/search?q=go→"go"；对路径或 body 无效 -
c.BodyParser(&v)必须传结构体地址：&user，不是user；且仅适用于Content-Type: application/json
真正麻烦的不是写不出“可选”效果，而是把 Params、QueryParam、BodyParser 的边界搞混，或者以为关个开关就能一劳永逸——结果路由行为越来越不可预测，debug 时得翻三遍文档才意识到是自己漏注册了一条路径。
