Go 后端实现与难点

状态：未准备（代码素材已整理，运行与个人分工待确认）

实现概览

源码根目录：SimulSpeak1。重点阅读 internal/api-server/httpapi/、internal/pbx/、internal/ai/、internal/registry/、internal/store/sqlite/。

api-server 处理业务接入、会话与字幕编排，PBX 负责媒体处理；AI 服务由 provider 适配，SQLite 存储业务数据，注册与调度支持 memory / etcd 场景。

难点与取舍

1. 信令与媒体职责划分

具体问题与背景：业务控制、模型调用和实时音频有不同的处理节奏与依赖。
我的实现（候选，待确认）：业务服务转发控制信令并选择媒体节点，PBX 持有 WebRTC 连接并执行媒体管线。
备选方案：单进程集中处理；业务服务转发全部音频。
选择理由与限制：职责清晰，允许分别调试和部署；引入节点发现、控制连接和跨组件排障成本。
结果与验证方式：跟踪同一会话的 WebSocket、SDP / ICE 和 PBX 日志，验证媒体实际路径。
代码路径 / 证据：internal/api-server/httpapi/pbx_bridge.go、internal/pbx/webrtc/manager.go。

2. 快翻、纠错与配音协调

具体问题与背景：只等待模型结果会推迟首译，不同句子的模型完成顺序也可能不同。
我的实现（候选，待确认）：快翻先提供草稿，模型结合上下文纠错；围绕句子状态、结果优先级和 TTS 协调器管理后续事件。
备选方案：只用机器翻译；只用 LLM；按返回先后直接派发配音。
选择理由与限制：在首译反馈和修订质量间取舍；配音按句序派发可能队首等待，派发顺序不等于已验证实际播放顺序。
结果与验证方式：注入快翻失败、模型失败、不同句子乱序完成和停止事件，检查字幕与配音派发；真实延迟待测。
代码路径 / 证据：internal/api-server/httpapi/interpreter.go、internal/api-server/httpapi/ai_media_test.go。

3. 节点发现与会话分配

具体问题与背景：多个 PBX 节点需要注册可用性并选择承接新会话的节点。
我的实现（候选，待确认）：通过注册中心维护节点信息，结合负载 / 轮询策略选择节点。
备选方案：固定单节点；外部负载均衡器。
选择理由与限制：便于本地与多节点模式切换；租约和负载有传播延迟，不提供存量 WebRTC 会话无感迁移保证。
结果与验证方式：启动两个节点，观察新会话分配；终止一个节点，分别检查新会话和已有会话。
代码路径 / 证据：internal/registry/registry.go、internal/registry/registry_test.go、pkg/client/balancer.go。

待完善项

全栈简历优先选前两项，再加一条前端字幕闭环；节点发现作为面试扩展即可。
确认真实 AI provider 接入、部署方式和本人工作范围。
不写未经实测的并发、毫秒延迟、翻译准确率和可用性。