最稳的库是uap-go，它是官方ua parser的go移植，规则持续更新，能准确识别新设备和系统；需正确安装、初始化并复用解析器实例，注意ua截断和编码问题。
Go里解析User-Agent字符串用哪个库最稳
直接上结论：用 uap-go，不是 golang-useragent，也不是手写正则。前者是官方UA Parser的Go移植，规则库持续更新，能识别新出的iOS 18、Chrome 127、折叠屏设备等；后者长期不维护，遇到 Mozilla/5.0 (Linux; Android 14; SM-F946B Build/UP1A.231005.007; wv) AppleWebKit/537.36 这类带 wv（WebView）标识的就直接漏判成“Unknown”。
安装命令：go get -u github.com/ua-parser/uap-go。注意别装错包名——常见错误是拼成 ua-parser-go（少个连字符）或 uaparser-go（多加了parser），会报 module not found。
关键点：初始化时必须加载内置规则文件，否则所有字段都是空。不能只 import，还得显式调用 uap.NewParser 并传入 uap.DefaultUserAgentParser。
解析结果里Device和OS字段为什么经常为空
不是代码写错了，是原始UA字符串本身信息不足。比如内网爬虫、旧版微信内置浏览器、某些IoT设备上报的UA可能是 Go-http-client/1.1 或 okhttp/4.9.3，压根不含设备型号或系统版本。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 先检查
ua.String()是否真实包含Android、iPad、WinNT等关键词，再查解析结果 -
parser.Parse返回的useragent.UserAgent结构体中，Device.Family和OS.Family是最可靠的字段，Device.Model和OS.Version很多时候是空字符串，别强依赖 - 遇到空值，可 fallback 到 UA 字符串的粗略匹配：比如含
Mobile且不含Tablet就当手机，含Windows NT 10.0就当 Win10+
高并发日志解析时CPU飙升怎么办
uap-go 默认每次 Parse 都做完整正则匹配，对每条日志重复编译规则，QPS 上千时 CPU 会卡在 regexp.(*Regexp).doExecute。
必须做的优化：
- 全局复用一个
*uap.Parser实例，不要每次请求都 new - 用
sync.Pool缓存useragent.UserAgent结构体，避免高频 GC - 如果只关心是否为移动端，用
parser.ParseShort（仅提取 Device.Family），比完整解析快 3–4 倍 - 日志中大量重复UA（如埋点SDK固定UA），加一层 LRU cache，key 是
uaString[0:128]（截断防长UA爆内存），value 是解析结果
示例缓存键构造：key := uaString → if len(uaString) > 128 { key = uaString[:128] }，别直接用全量字符串作 map key。
Web日志里UA被截断或编码导致解析失败
Nginx 或 CDN 日志中常见两种损坏：
- UA 被截断：Nginx 默认
$http_user_agent最大长度 4KB，但有些监控SDK上报的UA超 6KB，末尾变成... (truncated)—— 解析器看到省略号直接放弃整条 - URL 编码未解码：前端 JS 用
encodeURIComponent(navigator.userAgent)后传给后端，日志里存的是Mozilla%2F5.0%20%28iPhone%3B%20U%3B%20...，uap-go不会自动 decode
处理顺序必须是：先判断是否含 % 或 (truncated) → 再决定是否 url.PathUnescape → 最后传给 parser。别在解析后再尝试修复，已经来不及了。
容易忽略的一点：Go 的 url.QueryUnescape 会把 + 当空格处理，但 UA 里极少出现 +，用 url.PathUnescape 更安全，不会误转义路径符号。
复杂点在于，有些日志同时混着编码和未编码的UA，得靠启发式判断：比如字符串里有连续多个 %[0-9A-F]{2} 就走解码，否则跳过。没这层判断，解码失败会panic。
