直接用 io.Copy 合并翻译结果不可行，因翻译接口返回结构化 JSON 响应而非原始字节流；分段翻译需按原文顺序拼接，核心难点是分段语义完整性与结果有序聚合，而非并发本身。
直接用 io.Copy 合并翻译结果不可行——翻译接口返回的是结构化响应（如 JSON），不是原始字节流；分段翻译后必须按原文顺序拼接内容，不能靠流式搬运。核心难点在「分段语义完整性」和「结果有序聚合」，不是并发本身。
分段不能按字节切，得用 sentence boundary detection
中文无空格分词，英文有标点但缩写（如 “Dr.”、“U.S.A.”）会干扰切分。硬按字符数或单词数截断，会导致句子被劈开、翻译结果错乱甚至 API 拒绝（部分服务要求完整句子）。
- 用现成库做句切分：
github.com/ikawaha/kagome/v2（日文/中文）、github.com/goodsign/monday（多语言通用）或轻量级正则兜底（仅限英文）：regexp.MustCompile(`(? - 每段长度控制在 500 字符内（避开多数翻译 API 的单请求限制，如 Google Cloud Translation v3 默认 30KB，但语义段越短越稳）
- 切分后保留原始段落索引，别只存文本——后续排序和合并全靠它
并发调用必须带 context.WithTimeout + 限流 channel
不加控制地并发发 100 个翻译请求，大概率触发远端限流（429）或本地文件描述符耗尽（“too many open files”），尤其当后端是自建模型服务时。
- 初始化一个限流信号量：
sem := make(chan struct{}, 10)，控制最大并发为 10 - 每个请求前执行：
sem ；完成后用 <code>defer func() { 归还 - 每个请求绑定独立 context：
ctx, cancel := context.WithTimeout(parentCtx, 8*time.Second)，超时后自动中断连接和读取 - 别忘了复用
http.Client：设置Transport.MaxIdleConnsPerHost = 100，否则高并发下 TCP 连接池撑爆
结果聚合必须按原始分段序号写入预分配切片
用 map[int]TranslationResult 或 sync.Map 收集结果看似方便，但写放大、无序、GC 压力大；而分段索引是已知且连续的（0, 1, 2…），完全没必要动态结构。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 提前分配结果切片：
results := make([]string, len(sentences)) - 启动 goroutine 时把索引传进去：
go func(idx int, text string) { ... results[idx] = translatedText }(i, sentences[i]) - 所有 goroutine 启动完，用
wg.Wait()等待全部完成，再按顺序strings.Join(results, "") - 注意：只要每个 goroutine 只写自己对应的
results[i]，完全不需要锁或原子操作——这是分片设计天然的安全边界
合并前必须校验分段数量和 HTTP 状态码，不能只看 err == nil
翻译接口返回 200 但 body 是错误 JSON（如 {"error": "quota_exceeded"}），或者某段超时后 fallback 返回空字符串，都会导致最终文本漏段、错位、中间断层。
- 每个 goroutine 内部必须解析响应 body，检查 status 字段或 error 键是否存在
- 主流程等全部完成之后，先确认
len(results)是否等于原始段数；若有空值，立刻报错退出，不继续拼接 - 不要依赖 “成功调用 N 次” 就认为拿到 N 段结果——网络抖动、服务降级、token 过期都可能让某次调用静默失败
最易被忽略的一点：前端传来的长文本若含大量空白符、换行、零宽字符，句切分前必须 normalize —— 否则切出来的段首尾带不可见符，翻译结果可能被截断或格式错乱，这种问题在线上跑几天才暴露，查起来极难定位。
