要自动在海王出海翻译完成后发送给客户，核心是用事件驱动流程：翻译完成触发事件→生成发送内容并匹配语言模板→调用发送服务（邮件、短信、推送或API）→记录状态并重试。关键点有可靠回调、模板变量替换、队列限流、失败重试、日志监控与数据合规。下面逐步拆解并给出可执行操作。示例代码与配置样例见正文操作清单。
先把流程弄清楚——用一句话理解整个系统
想象把翻译当成一个“作业”。作业完成时，系统要把“完成单”送到客户手里（邮件、短信或第三方系统）。要做到自动发送，需要四个组件配合：触发（event）、内容生成与本地化（template + i18n）、发送通道（mailer/sms/api）、以及可靠性保障（队列、重试、监控）。
为什么要用事件驱动？
事件驱动把“完成信号”和“发送动作”解耦。翻译微服务只负责写入状态和发出事件，发送服务订阅事件并负责投递。这样便于扩展不同发送渠道，也能更灵活地做重试、限流和审计。
事件模型与数据结构（简单到能实现）
每次翻译任务都要有一个唯一ID（job_id），完成时推送一个标准的事件负载。负载至少包含：job_id、用户ID、目标语言、附件（或下载链接）、客户偏好（邮件/短信/API回调）、时间戳和签名（用于验证）。
示例事件负载（JSON 形式）
{“job_id”:”12345″,”user_id”:”u678″,”lang”:”es”,”channel”:”email”,”email”:”[email protected]”,”attachments”:[“https://…/file.pdf”],”completed_at”:”2026-06-16T10:00:00Z”,”signature”:”…”}。签名用于防止伪造回调。
关键模块详解（一步一步做）
1）翻译完成触发
- 在翻译服务里，翻译流程最后一步写入数据库状态为 completed，并把事件发到消息总线（如 RabbitMQ / Kafka / AWS SNS）或直接调用发送服务的 webhook。
- 如果采用数据库+事件总线，务必使用事务出发模式（写入状态和发布事件的一致性）。
2）事件接收与校验
- 接收服务要校验签名与 job_id 是否真实，防止重放攻击。
- 把事件放入发送队列（如 SQS / RabbitMQ）。队列负责削峰与保证至少一次投递。
3）内容生成与多语言模板
在生成发送内容时要做两件事：替换变量（客户名、产品名、下载链接）和做文化适配（日期格式、称呼、礼貌语气）。建议把模板按语言与场景分开管理，例如：
- email/order_complete/zh-CN.html
- email/order_complete/es-ES.html
- sms/order_complete/en-US.txt
模板中用占位符（{{customer_name}}）并在发送前用渲染引擎替换。模板版本要可回滚，改动要记录差异。
4）发送通道适配
不同客户偏好和国家/地区限制决定发送通道：邮件通常用 SMTP 或第三方服务（SendGrid、Mailgun、阿里云邮件等）；短信用本地化合作方或者 Twilio/阿里云短信；API 回调直接 POST 到客户提供的接收端。发送逻辑要封装成统一接口：
- sendMessage(job_id, channel, payload) → 返回发送任务ID
接口内部再做每个渠道的实现细节（重试、并发控制）。
5）队列、重试与死信
发送失败要分级处理：
- 短期网络或服务错误：指数退避重试（例如 1min、5min、20min、60min）
- 永久错误（400 系列）：记录失败并通知运维或业务（不再重试）
- 超过最大尝试次数：写入死信队列（DLQ）并标记为需要人工处理
| 参数 | 示例值 |
| 最大重试次数 | 5 |
| 重试间隔（指数退避） | 60s, 300s, 1200s, 3600s, 86400s |
6）状态记录与回调
每次发送都要把状态写回主库或日志系统：pending → sending → success/failure。若客户要求回调，发送成功后向客户提供的回调 URL POST 状态，回调也要重试并对回调结果做记录。
7）监控、告警与审计
要监控以下指标：队列深度、发送成功率、平均延迟、失败原因分布和死信数量。出现异常（如成功率低于 95%）时自动告警。审计日志需保留一定周期，方便追溯。
运营细节：本地化与合规不可忽视
发送给海外用户有很多细节：
- 收件人偏好：用户是否同意接收通知（GDPR/隐私条款）？
- 语言与格式：邮件主题、称呼、货币、时间格式要按目标语言展示。
- 退订与转人工：邮件需要明显退订链接，短信需要明确指令说明。
- 本地法规：某些国家对短信或邮件营销有限制，发送前要核查。
示例实现片段与配置样例
示例：Webhook 接收伪代码（伪 JS）
下面是一个简化流程，展示接收事件并入队的思路：
function onTranslateCompleted(payload){ if(!verifySignature(payload)) return 401; enqueue(‘send-queue’, payload); updateJobStatus(payload.job_id,’queued’); }
示例：邮件模板（简化）
Subject（es-ES）: Su traducción está lista — {{project_name}}
Body（es-ES）: Hola {{customer_name}}, su traducción para {{project_name}} está completa. Puede descargarla aquí: {{download_link}}. Gracias por usar nuestro servicio.
示例：队列与重试配置（建议）
| 队列类型 | 独立发送队列（按通道/优先级分级） |
| 并发消费者 | 根据渠道限流：邮件 50/s，短信 10/s（示例） |
| 死信处理 | 写入 DLQ 并触发人工工单 |
测试与上线步骤（一步步来）
- 单元测试：模板渲染、签名校验、重试算法。
- 集成测试：全流程测试（模拟翻译完成→事件→队列→发送）。
- 灰度发布：先对小量真实用户开启自动发送，观察失败率与用户反馈。
- 安全测试：对回调接口做穿透测试，验证签名与权限。
运维清单（上线前必须做的 12 项）
- 配置签名与密钥管理
- 建立队列与死信队列
- 搭建监控 Dashboard（成功率、延迟、队列深度）
- 准备异常告警策略
- 整理多语言模板并做审核
- 配置渠道限流参数
- 准备回滚与降级策略（例如：翻译完成后只存档不自动发送）
- 测试回调与客户接收方可靠性
- 确认合规与隐私政策覆盖目标市场
- 准备人工处理流程（DLQ 工单）
- 演练意外场景（第三方邮件服务宕机）
- 记录并保存审计日志（至少 90 天）
常见问题与解决思路（实操经验）
- 邮件被当成垃圾邮件：检查发件域名 SPF/DKIM/DMARC，控制发送频率，改善内容质量。
- 回调丢失或延迟：引入幂等设计（基于 job_id），并对回调设置重试与手动补偿接口。
- 模板翻译错误：建立翻译校对流水线，关键文案走人工审校。
- 海外短信失败：使用本地运营商或合作方，按目的国配置路由和签名规范。
小提示：让自动发送更“人性”一些
自动发送并不意味着生硬的机器信件。简单做法包括：在邮件里加入客服联系人、本地化问候语、以及针对不同语言的礼貌语序。对于品牌文案，尽量用人工校对后的 Slogan 版本而非直译，能显著提升用户体验。
好了，说到这里，你已经有一套从事件触发到最终送达的完整思路和可执行步骤。实施时先做最小可运行版本（MVP）：翻译服务发事件→接收服务入队并发送简单邮件→记录状态；把复杂的限流、重试规则和多模板留到第二阶段逐步完善。实操中会遇到各种小坑，像是时区问题、编码/附件大小限制、第三方厂商费用上限等，那些可以通过监控和逐步迭代来解决，别一次想把全部都做完。祝顺利搭建出又稳又暖的自动发送流程。