Go net/mail.Address.String 为什么会自动给显示名加引号

用 Go 生成邮件头时，下面这段代码经常让人困惑：明明 Name 只是普通文本，Address.String() 却在显示名两侧加上了双引号。原因是它不是字符串拼接工具，而是把 Address 重新格式化成合法的 RFC 5322 邮件地址；引号是语法的一部分，用来保留显示名中的空格和特殊字符。

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

只要输出目标是邮件头地址，就应优先让 net/mail 负责格式化。可打印 ASCII 名称通常会输出为 quoted-string；包含非 ASCII 字符的名称会转成 RFC 2047 encoded-word。不要再对最终字符串手动包一层引号。

先把 Name 和 Address 分开看

mail.Address 有两个不同职责的字段：Name 是收件人看到的显示名，Address 是真正的 local-part@domain 地址。String 方法需要同时处理这两部分，最终才拼成一个可放进 From、To 或 Reply-To 的地址。

package main

import (
    "fmt"
    "net/mail"
)

func main() {
    // Name 是显示文本，Address 才是邮箱地址本体。
    a := &mail.Address{Name: "研发组", Address: "dev@example.com"}
    fmt.Println(a.String())

    // 直接使用 String，避免手写尖括号、引号和转义规则。
    plain := &mail.Address{Name: "Dev Team", Address: "dev@example.com"}
    fmt.Println(plain.String())
}

这里的重点不是把两个字段连接起来，而是让库根据邮件地址语法选择表示方式。空的 Name 会省略显示名，只返回尖括号包裹的地址本体；有显示名时，才进入显示名格式化分支。

可打印 ASCII 显示名为什么会带引号

邮件地址里的显示名属于地址语法中的 phrase。Name 里如果有空格、逗号、括号、双引号或反斜杠，直接裸写会让解析器难以判断文本边界。Go 的实现对可打印 ASCII 名称统一使用 quoted-string，并在需要时对特殊字符进行转义。

因此看到下面的结果时，不要把引号理解成 Name 被改成了新内容：

// 说明：输出中的双引号是邮件地址语法，不是业务名称的一部分。
a := &mail.Address{Name: "Dev Team", Address: "dev@example.com"}
fmt.Println(a.String())

// 典型格式："Dev Team" 

解析器再次读取这个字符串时，可以把双引号去掉，还原出 Name == "Dev Team"。这就是 quoted-string 的价值：它保留显示名中的空格，同时明确显示名与地址本体的边界。自己写成 Name + " "，很容易漏掉这些规则。

中文显示名不是普通双引号路径

如果 Name 含有中文或其他非 ASCII 字符，Address.String 会按照 RFC 2047 生成 encoded-word。你可能看到类似 =?utf-8?q?...?= 或 =?utf-8?b?...?= 的结果，这不是乱码，而是邮件头传输格式。

package main

import (
    "fmt"
    "net/mail"
)

func main() {
    // 非 ASCII 显示名由 net/mail 负责编码，业务层不要自行 Base64 或 URL 编码。
    sender := &mail.Address{Name: "研发组", Address: "dev@example.com"}
    headerValue := sender.String()
    fmt.Println(headerValue)
}

这里不要拿编码后的显示名去做业务比较。需要比较联系人名称时，比较 Address.Name；需要写入邮件头时，使用 String() 的结果。显示名编码和地址校验是两件事，String 负责格式化，不负责替你验证邮箱是否真实存在。

生成邮件头时的推荐流程

把联系人数据先放入 mail.Address，写入邮件头前调用一次 String()。读取已有邮件头时则使用 mail.ParseAddress，让解析过程负责还原引号和 encoded-word。

// 生成：只在写入邮件头的边界调用 String。
from := (&mail.Address{Name: "研发组", Address: "dev@example.com"}).String()
header := "From: " + from

// 解析：拿到结构化字段后，不要继续操作编码后的原始文本。
parsed, err := mail.ParseAddress(from)
if err != nil {
    // 生产代码应记录格式化输入并返回错误，避免发送无效邮件头。
    return err
}
fmt.Println(parsed.Name, parsed.Address)

有三个常见误区：第一，给 String() 的完整结果再加双引号；第二，把 RFC 2047 编码当作名称内容保存；第三，把显示名的格式化成功误认为地址可投递。前两个会破坏头部格式，最后一个则混淆了语法格式化与业务校验。

速查与相关问题

为什么不用字符串拼接代替 Address.String？

因为拼接只能覆盖最简单的英文名称，无法可靠处理空格、特殊字符、转义和非 ASCII 邮件头编码。

Address.String 会检查邮箱是否存在吗？

不会。它做的是语法格式化；域名可达性、账号存在性和投递结果需要由其他系统处理。

记住一个判断标准：邮件头边界交给 net/mail 格式化，业务逻辑内部保留未编码的 Name 与 Address。看到自动引号时，先把它当成 RFC 语法保护，而不是异常输出。