应显式设置 http.Client.Timeout（文本≤3s、图片≤8s），用 context.WithTimeout 细粒度控制超时，通过 semaphore.NewWeighted 限流，并用 io.LimitReader 防止响应体过大导致阻塞。
用 Go 调用 AI 审核 API 时，怎么避免阻塞和超时雪崩？
Go 本身不带 AI 模型推理能力，实际审核依赖外部服务（如腾讯云TMS、百度内容安全、或自建的 FastAPI/ONNX Runtime 服务）。关键不是“怎么写模型”，而是“怎么稳、快、可控地调用它”。
常见错误是直接 http.DefaultClient.Do() 同步发请求，一卡全卡，再加个没设 timeout 的 client，整条 HTTP 链路就挂死。
- 必须显式设置
http.Client.Timeout，建议 ≤ 3s（文本类）或 ≤ 8s（图片/OCR 类） - 用
context.WithTimeout()包裹请求，比 client timeout 更细粒度，能提前 cancel 连接 - 高并发下要限制并发数，别让 goroutine 疯涨——用
semaphore.NewWeighted(10)或带缓冲的 channel 控制 - 别在 handler 里直接
json.Unmarshal原始响应体；先用io.LimitReader(resp.Body, 2 防止大响应体 OOM
如何设计审核结果缓存，避免重复调用和误判放大？
AI 接口有费用、延迟、概率性抖动。同一段文本/图片短时间内反复送审，既浪费钱，又可能因模型临时波动返回不一致结果（比如前次“正常”，后次“涉政”），导致业务逻辑混乱。
缓存不是简单套 Redis，得带语义和策略：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- key 要包含内容指纹 + 审核策略 ID，例如
audit:sha256:<hash>:policy:v2</hash>，避免策略升级后命中旧结果 - value 必须存完整响应结构（含
review_id、suggestion、labels），不能只存布尔值 - 缓存时间按风险等级分层：低风险（如普通评论）TTL=1h，中风险（用户头像）TTL=24h，高风险（举报内容）不缓存或 TTL=5m
- 加一层本地 LRU（如
github.com/hashicorp/golang-lru/v2），拦截高频重复请求，减轻 Redis 和上游压力
文本预处理怎么做，才能让 AI 审核更准、更省？
直接把原始用户输入扔给 API，效果差、成本高。Go 层要做轻量但有效的清洗和归一化，本质是减少噪声、对齐模型训练分布。
- 用
strings.TrimSpace()+regexp.MustCompile(`\s+`).ReplaceAllString()` 干掉多余空白，防止“ 敏感词 ”绕过</li> <li>统一繁体转简体（用 <code>github.com/go-cc/cc
），避免“裡”“後”等字漏判 - URL、邮箱、手机号用正则替换为占位符（如
[url]），既保留结构信息，又去掉干扰 token - 对长文本做分块：按句号/换行切分，跳过纯数字、纯符号段落，再合并为 ≤ 500 字的片段分别送审——比整段送审准确率高 12%+（实测）
审核失败或结果异常时，Go 怎么兜底不中断业务？
AI 服务不可靠是常态：HTTP 503、模型返回 "error": "timeout"、字段缺失、甚至整个 region 断连。硬抛 panic 或返回 500 给前端，等于把技术问题转嫁给用户。
- 定义明确 fallback 策略：如
if err != nil || resp.Suggestion == "" { return "review_pending", nil }，让业务层决定是放行、限流还是人工复审 - 对
429 Too Many Requests响应，提取Retry-Afterheader，用time.Sleep()退避，而不是立刻重试 - 记录结构化日志：
zap.String("audit_id", id), zap.String("upstream", "tencent"), zap.Error(err)，别只打fmt.Println - 关键路径上加熔断器（如
sony/gobreaker），连续 5 次失败自动半开 30 秒，避免雪崩
真正难的不是调通一个接口，而是当上游返回 {"code": 200, "msg": "success", "result": null} 时，你代码里有没有判断 resp.Result != nil 就直接解包——这种空指针 panic，在审核系统里往往发生在凌晨三点，且只影响 0.3% 的请求，最难复现。
