http.Server 不提供多路复用器，路由分发由 http.ServeMux 或第三方路由器（如 gorilla/mux、gin）实现；ServeMux 仅线性匹配前缀，无路径参数支持；真正 I/O 多路复用由 net 包底层封装 epoll/kqueue，对用户透明。
Go 标准库的 http.Server 本身不提供“多路复用器”这个抽象层——它只负责监听连接、分发请求；真正承担路由分发职责的是 http.ServeMux 或第三方实现（如 gorilla/mux、gin.Engine）。所谓“框架内部的多路复用器”，本质是**HTTP 路由匹配逻辑**，不是 I/O 层的 epoll/kqueue 多路复用。
http.ServeMux 的匹配逻辑是线性遍历，不是哈希或 trie
http.ServeMux 内部用 map[string]muxEntry 存注册的固定路径（如 /api/users），但对带变量的路径（如 /api/users/:id）完全不支持。它的“多路”仅体现在：同一 server 实例可注册多个 HandleFunc，靠字符串前缀匹配和最长匹配规则决定谁处理请求。
- 注册
/和/api后，/api/users会命中/api（因为它是最长匹配前缀） - 没有通配、正则、路径参数提取能力；所有复杂路由必须手动解析
r.URL.Path - 性能随注册路径数线性下降，1000 条路由就可能成为瓶颈
第三方路由器如何实现真正的“多路”匹配
像 gorilla/mux 或 chi.Router 才具备工业级路由能力，它们用 trie（前缀树）或 radix tree 结构组织路径规则：
-
GET /users/{id}和POST /users被拆解为节点路径，在树中分叉存储 - 匹配时按 URL path segment 逐层下探，时间复杂度接近 O(n)，与规则总数无关
- 支持方法区分（
GET/POST不共享同一节点）、正则约束（{id:[0-9]+}）、中间件链注入
注意：gin 的路由树还做了内存优化——相同前缀的子节点共用一个数组，减少指针跳转开销。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
net/http 底层才是真正的 I/O 多路复用，但对用户透明
你写的 http.ListenAndServe 启动后，Go 运行时在底层调用 epoll_ctl（Linux）或 kqueue（macOS）监听 socket 事件。这部分由 net 包封装，开发者完全感知不到：
- 每个新连接到来，内核通知 Go runtime，runtime 唤醒一个空闲
M（OS 线程）去 accept - accept 后立即启动新 goroutine 处理该连接的读写，原
M继续等待下一个事件 - 整个过程无需用户代码参与调度，也不需要你写
select监听 fd
所以别在 handler 里自己搞 select 去“复用连接”——那是重复造轮子，且大概率出错。
自定义中间件或拦截器不是多路复用器，而是责任链
很多人把 Gin 的 Use() 或 chi 的 MiddlewareFunc 当成“多路复用”，其实不是：
- 它们只是在请求进入最终 handler 前/后插入函数，执行顺序固定（注册顺序）
- 没有分支选择逻辑，不决定“哪个 handler 处理请求”，只做通用增强（日志、鉴权、panic 捕获）
- 真正的路由分发发生在中间件链之前，由路由器完成
如果你看到某个框架文档说“内置多路复用中间件”，基本是营销话术，实际就是个 for 循环调用函数列表。
真正容易被忽略的点是：路由匹配和 I/O 多路复用属于不同层级。前者解决“该让谁处理”，后者解决“怎么高效收发数据”。混淆这两者，就会在不该动手的地方硬加 select 或自己实现 epoll 封装，反而破坏 Go 的运行时契约。
