Go net/mail ParseAddressList 怎样解析多个收件人

在 Go 中解析多个收件人，直接使用 mail.ParseAddressList。它接收一个地址列表字符串，返回 []*mail.Address；每个对象的 Name 保存显示名，Address 保存邮箱地址。把“返回数量、字段内容、错误值”作为三个验收指标，就能避免手写逗号切分带来的边界问题。

官方地址：https://pkg.go.dev/net/mail#ParseAddressList

输入是邮件头或配置中的地址列表时，不要先用 strings.Split 拆字符串；先交给 ParseAddressList，成功后再遍历每个 mail.Address。

先确定地址列表的输入和验收指标

本例把三条地址作为基线：两条带显示名，一条只有邮箱地址。预期返回数量为 3；带显示名的条目能读到 Name，纯地址条目的 Name 为空；只要解析返回错误，就不把这批结果继续交给发信逻辑。

package main

import (
	"fmt"
	"log"
	"net/mail"
)

func main() {
	// 地址列表可以来自邮件头、配置文件或表单字段。
	raw := "Alice , Bob , ops@example.com"

	// 让标准库按邮件地址列表语法解析，不手写逗号切分规则。
	addresses, err := mail.ParseAddressList(raw)
	if err != nil {
		// 解析失败时停止使用这批数据，避免产生不完整的收件人集合。
		log.Fatalf("parse recipients: %v", err)
	}

	// 返回数量是第一个可复现的验收指标。
	fmt.Printf("count=%d\n", len(addresses))
	for i, address := range addresses {
		// Name 与 Address 分开读取，便于后续组装邮件或日志字段。
		fmt.Printf("%d: name=%q address=%q\n", i, address.Name, address.Address)
	}
}

这个示例的预期指标是 count=3。重点不是把地址打印出来，而是确认解析器返回了结构化对象，调用方不必再猜测显示名和地址之间的分隔关系。

用 Name 和 Address 区分两种收件人写法

mail.Address 表示一个地址对象，官方文档给出的字段就是 Name 和 Address。因此业务代码应读取字段，而不是再对 String() 的格式化结果做字符串截取。

如果需要重新格式化单个地址，可以使用 Address.String()；它属于输出格式化职责，不应替代列表解析。非 ASCII 显示名的编码输出也由该类型负责。

为什么不要用 strings.Split 手动拆分

逗号在地址列表语法中不是简单的业务分隔符。显示名、引用文本和邮件头空白都可能让“按逗号切开再逐项处理”的代码变得脆弱。ParseAddressList 面向 RFC 5322 并扩展 RFC 6532 的地址语法；官方文档也明确说明，它不解析部分过时地址格式，不支持完整的 CFWS 空白语法，也不做 Unicode 规范化。

对表单或配置输入，建议采用“整批成功、整批失败”的策略：

import "fmt"

func parseRecipients(raw string) ([]*mail.Address, error) {
	// 一个地址列表对应一次解析，保留标准库返回的错误信息。
	addresses, err := mail.ParseAddressList(raw)
	if err != nil {
		// 不把可能不完整的切片交给发送层或持久化层。
		return nil, fmt.Errorf("invalid recipient list: %w", err)
	}

	// 由调用方决定是否还要检查数量上限或业务黑名单。
	return addresses, nil
}

如果产品确实允许“跳过坏地址、继续处理好地址”，应单独设计逐项输入和错误报告模型，而不是把一个有错误的列表返回值当成完整结果。解析库负责语法，不负责收件人去重、权限判断或发送邮件。

用三个指标判断这次解析是否可用

性能案例中的“基线”可以先落在可复查的结构化指标上，而不是凭感觉说解析成功：

这三个指标能区分“解析成功”和“业务可发送”。例如解析器可以正确返回多个地址，但数量上限、重复地址、域名策略仍然属于业务层。把职责拆开，后续改动更容易定位。

常见问题

ParseAddressList 能不能只解析一个邮箱地址？

可以处理只含一个地址的列表，但如果代码明确只接受单个地址，使用 mail.ParseAddress 表达意图更清楚。列表解析与单地址解析是两个不同的入口。

解析失败时能不能继续使用已经返回的部分地址？

应用层不应默认使用部分结果。把错误当作整批失败，能够避免收件人列表被静默截断；只有在产品明确设计了逐项容错和错误回显时，才另行实现对应的数据模型。

小结：先用 ParseAddressList 得到结构化地址对象，再用数量、字段和错误三个指标验收；不要手写逗号拆分，也不要让解析库承担去重、限额和发信策略。