Phorge 现代化改造实战（七）：迁移邮件服务，先分清哪些失败不该重试
内容提要
本文介绍Phorge邮件系统现代化改造，将独立gorge-mailer迁入Gorge单仓库，统一SMTP及第三方provider后端。核心修复包括：永久失败错误分类、重试参数生效、就绪探针真实化、配置合并防覆盖。强调失败需让负责层可见，避免静默故障，并指出需区分后端与整封邮件的永久失败作用域。
延伸解读
永久失败分类的边界
文章指出，当前实现将除429外的provider HTTP 4xx都归为永久失败，但其中既包括无效收件人，也可能包括凭据撤销等仅对当前后端成立的问题。作者建议将PermanentError拆分为“message permanent”和“backend permanent”，或携带scope，以避免将后端配置错误过早升级为整封邮件的永久失败。
重试参数的默认值调整
旧配置中的MaxRetries=250和RetryWait=15s从未被读取，若直接启用会导致约62分钟的重试，远超PHP客户端30秒超时。r1将默认值改为2次重试、间隔2秒，并确保MaxRetries×RetryWait≤10s，以显著小于客户端预算。测试还防止未来修改时忽略这一约束。
就绪探针的真实性
旧服务在无后端时仍返回/healthz 200，导致“活着但无投递能力”被误判为健康。新实现使用/readyz检查是否至少配置了一个适配器，但不过度探测第三方可用性，因为provider抖动应由failover吸收。探针只承诺“能尝试发送”，不承诺邮件一定到达。
配置合并防覆盖
容器启动脚本不再整体覆盖cluster.mailers，而是按key删除后合并，避免其他发信路径被静默移除。同时只读取source=local的值，防止遮蔽数据库配置。读取或解析失败时宁可不写，因为覆盖错误往往没有现场可恢复。
Q&A
Phorge邮件服务迁移中，为什么永久失败从未被标记为永久？
旧实现中虽然定义了PermanentError类型，但七个后端没有任何一个实际返回过它，导致收件人地址错误等永久失败被当作临时失败不断重试。
在邮件重试中，429状态码为什么不能视为永久失败？
429表示限流，是临时状态，稍后可能成功。若判为永久失败，会导致本可发出的邮件被立即标记为FAIL，造成静默丢失。
Phorge邮件服务中，重试参数MaxRetries和RetryWait为什么之前没有生效？
旧配置中虽有MaxRetries=250和RetryWait=15s，但发送路径从未读取它们，实际每个后端只尝试一次。迁移时若直接启用，会导致重试时间远超PHP客户端30秒超时，造成两套重试叠加。
Phorge邮件服务中，/readyz探针的作用是什么？
/readyz用于检查是否至少配置了一个邮件后端，若没有则返回错误，使容器不健康。它只承诺进程能尝试发送，不保证第三方可用，避免将provider抖动误判为不健康。
Phorge邮件服务配置合并时，为什么要先按key删除再写入？
按key删除可解决幂等问题，避免重复key导致配置写入失败；同时不按type删除，允许用户配置多个指向不同实例的gorge adapter。
Phorge邮件服务中，为什么inbound能力声明要设为false？
因为Gorge mailer只做出站邮件，若inbound默认为true且未覆盖，Phorge会误将其视为收信入口，影响收信能力计算。
Phorge邮件服务中，为什么supports-message-id默认设为false？
因为SendGrid和Postmark会覆盖Message-ID，而PHP adapter无法知道最终使用哪个后端，设为false是保守诚实的答案，避免谎报导致客户端会话串接失效。
Phorge邮件服务中，为什么无效JSON请求应返回400而不是500？
无效JSON请求无法成功，若返回500，Phorge worker会对其持续重试，浪费资源。返回400 ERR_BAD_REQUEST可避免重试循环。
