Go标准库http.ServeMux不支持通配符和动态参数，因其仅做前缀字符串匹配，无法识别*或:id语义；需用gorilla/mux等第三方库或基于Trie树自实现，且*节点必须限定在路径末尾并贪婪匹配剩余段。
Go 标准库的 http.ServeMux 不支持通配符匹配，必须用第三方库或自定义实现；硬写正则兜底路由容易失控，真正可控的方式是基于前缀树（Trie）+ 显式通配节点设计。
为什么 http.ServeMux 不能直接支持 * 和 :id
它只做前缀字符串比较，遇到 /user/* 或 /users/:id 这类模式时，根本不会识别通配语义。你注册 /user/，它能匹配 /user/123，但无法提取 123 作为参数值，更不会区分 /user/profile 和 /user/123 的处理逻辑。所有“通配”行为都得靠你自己在 handler 里用 strings.Split 或 regexp 拆解 r.URL.Path，既难维护又易出错。
用 gorilla/mux 实现 * 通配路径的正确姿势
gorilla/mux 支持 {name:.*} 形式的正则约束，但真要用通配符捕获多段路径（比如 /static/*filepath），必须用 PathPrefix + Subrouter 组合，而不是想当然地写 Handle("/static/*", h)——它不认这个语法。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
PathPrefix("/static/").HandlerFunc(staticHandler)是合法的，但不提取参数 - 要提取剩余路径，得手动截取：
filepath := strings.TrimPrefix(r.URL.Path, "/static/") - 若需严格匹配末尾通配（如
/files/{path:.*}），必须确保正则末尾加$，否则可能跨段误匹配 - 注册
/files/{path:.*}后，r.URL.Path是原始路径，mux.Vars(r)["path"]才是解码后的段内容（不含%2F）
手写 Trie 路由时，* 节点必须满足两个硬约束
自己实现通配路由不是把 * 当成普通节点塞进树里就完事。它本质是一个“贪婪吞掉后续所有非空段”的终结符，所以必须强制限制它的位置和行为：
-
*只能出现在路径最后一段，即/api/v1/*✅，而/api/*/v1❌（无法界定“中间 *”的边界） - 匹配时，一旦进入
*节点，就不再逐段比对，而是把剩余全部路径段拼成一个字符串（用/连接），赋给filepath参数 - 多个
:参数连续出现没问题（如/a/:x/:y），但/a/:x/b/:y中的b必须字面精确匹配，不能被:覆盖 - 别预编译正则去匹配每条路由——每次请求都要跑 N 条正则，性能崩得比树查找快得多
别在 HTTP 路由里复用 MQTT 的 +/# 逻辑
MQTT 主题通配符（+ 单层、# 多层末尾）和 HTTP 路径通配语义完全不同。有人试图照搬 github.com/eclipse/paho.mqtt.golang.TopicMatch 到 Web 路由里，结果发现 a/+/c 匹配不了 a/x/y/c——这没错，因为 MQTT 里 + 就是单层。HTTP 路由没有这种协议级约束，/a/*/c 如果真要支持，必须自己定义规则并严格执行，不能假定别人也按 MQTT 解释。
最容易被忽略的是：通配匹配成功后，提取出的参数值默认是 URL 解码过的，但如果你在 handler 里又拿它拼回 URL 或传给下游服务，得确认对方是否需要原始编码形式——比如 /user/name%2Fspace 解码后是 name/space，再编码回去可能变成 name%20space，语义已变。
