Go x/net/idna.ToASCII 为什么与直接转小写不同

先说结论：idna.ToASCII 不是 strings.ToLower 的域名版。Go 官方文档把它定义为 Punycode.ToASCII 的包装，它的任务是把域名或标签编码成 ASCII 表示，并不会承诺把已有的 ASCII 字母统一转成小写。需要按域名查找规则做大小写、宽度和兼容映射时，应使用 idna.Lookup.ToASCII。

官方文档：https://pkg.go.dev/golang.org/x/net/idna#ToASCII

把问题拆成三个目标就不会混淆：只要原始 Punycode 编码就用 idna.ToASCII；要把用户输入整理成查找键就用 idna.Lookup.ToASCII；要判断一个名称能否注册就用 idna.Registration.ToASCII，不要用转小写来代替 IDNA 校验。

为什么 idna.ToASCII 不等于直接转小写

strings.ToLower 做的是 Unicode 字符串的大小写转换，而 idna.ToASCII 处理的是 IDN 到 ASCII 的表示转换。两者的输入输出契约不同：前者关注字符大小写，后者关注域名标签是否需要 Punycode 编码以及怎样得到 ASCII 形式。

官方文档明确写着顶层 ToASCII 是 Punycode.ToASCII 的包装。原始 Punycode Profile 不做映射，尤其不会替你做域名查找需要的大小写、宽度和兼容字符整理。因此，输入中的 ASCII 大写可能保留；输入中包含非 ASCII 字符时，才会出现 xn-- 形式的编码标签。

所以，下面两个调用即使都接收字符串，也不能互相替换：

package main

import (
	"fmt"
	"strings"

	"golang.org/x/net/idna"
)

func main() {
	input := "WWW.GÖPHER.com"

	// ToLower 只做字符大小写转换，不负责把非 ASCII 域名编码成 Punycode。
	lower := strings.ToLower(input)

	// 顶层 ToASCII 走原始 Punycode Profile，不等同于查找场景的统一小写。
	ascii, err := idna.ToASCII(input)
	if err != nil {
		// IDNA 转换失败时，错误比猜测一个小写结果更重要。
		fmt.Println("ToASCII error:", err)
		return
	}

	fmt.Println("lower:", lower)
	fmt.Println("ascii:", ascii)
}

这段代码的重点不是比较某个固定字符串的输出，而是确认职责：小写操作不会自动提供 Punycode；原始 ToASCII 也不会自动提供查找 Profile 的映射。若业务把结果作为域名键保存，必须先决定自己要的是编码结果还是规范化后的查找键。

域名查找为什么应该用 idna.Lookup.ToASCII

idna.Lookup 是官方提供的查找 Profile。文档说明 MapForLookup 会按照查找场景做规范化，以及大小写、宽度和其他兼容映射；它的目标是让用户输入经过一致的 IDN 处理后再参与域名查找。

这一步和手动调用 strings.ToLower 的区别在于，域名查找并不只有大小写问题。全角字符、兼容字符、规范化形式以及 IDNA 允许的标签规则，都可能影响最终的 ASCII 键。手动小写只能覆盖其中一个很窄的维度。

package main

import (
	"fmt"
	"golang.org/x/net/idna"
)

func lookupKey(domain string) (string, error) {
	// Lookup Profile 负责查找前的 IDNA 映射，不用手工拼接多个字符串规则。
	return idna.Lookup.ToASCII(domain)
}

func main() {
	key, err := lookupKey("www.GÖPHER.com")
	if err != nil {
		// 查找键生成失败时拒绝继续查询，避免把未处理的输入当成可靠键。
		fmt.Println("lookup key error:", err)
		return
	}
	fmt.Println(key)
}

如果系统还需要 Bidi 规则校验，不能假设 MapForLookup 自动添加了它。官方文档特别说明，查找映射本身不添加 Bidi Rule，需要时显式组合 idna.BidiRule() 与其他 Profile 选项。

注册校验和查找映射不是同一条链路

域名注册场景的目标不是“尽量把输入变成可查询的键”，而是判断给定 IDN 是否满足注册格式。idna.Registration 使用 ValidateForRegistration 配置，遇到不允许的字符或格式会返回错误。此时先调用 strings.ToLower 再提交，可能会改变证据，让排查者看不出原始输入的问题。

package main

import (
	"fmt"
	"golang.org/x/net/idna"
)

func registrationASCII(domain string) error {
	// Registration Profile 用于判断注册格式，不把查找映射当成注册许可。
	ascii, err := idna.Registration.ToASCII(domain)
	if err != nil {
		// 保留原始错误，调用方才能提示用户修正具体输入。
		return fmt.Errorf("注册名称无效：%w", err)
	}
	fmt.Println("registration form:", ascii)
	return nil
}

可以把这两个 Profile 放在不同的系统边界：解析用户输入并发起查询时使用 Lookup；管理注册申请或校验数据时使用 Registration。它们都能产生 ASCII 结果，但“产生结果”的理由不同，不能用结果字符串是否看起来像小写来判断是否合法。

遇到 error 时不要只看返回字符串

Profile.ToASCII 的文档说明：如果转换遇到错误，会返回错误以及一个“部分处理”的结果。这意味着返回的字符串不能在 err != nil 时被当成完整域名键，也不应该为了得到一个看似可用的结果而忽略错误。

func safeASCII(profile *idna.Profile, input string) (string, error) {
	// ToASCII 的返回值可能只是部分处理结果，因此先判断 error。
	result, err := profile.ToASCII(input)
	if err != nil {
		// 记录结果只能用于诊断，不能把它写入正式查找或注册数据。
		return "", fmt.Errorf("IDNA 转换失败，部分结果 %q：%w", result, err)
	}
	return result, nil
}

工程上还要避免一个常见误区：把所有域名输入都先做 strings.ToLower，再根据字符串是否变化来判断“是否标准化完成”。正确的判断应该来自所选 Profile 的成功或失败，以及业务对查找、显示、注册的明确要求。

按目标选择 API 的排查清单

1. 只是需要原始 ASCII 表示吗？ 使用 idna.ToASCII，并接受它不会替你做查找映射。
2. 结果要作为域名查询键吗？ 使用 idna.Lookup.ToASCII，不要自己用小写、宽度转换和兼容字符替换拼规则。
3. 结果要用于注册校验吗？ 使用 idna.Registration.ToASCII，把错误视为输入不符合注册要求，而不是自动修正。
4. 是否还需要双向文本规则？ 查阅 Profile 选项并显式加入 idna.BidiRule()，不要把查找映射误认为完整校验。
5. 是否忽略了 error？ 不要使用部分处理结果；先让调用方决定提示、拒绝还是重新输入。

常见问题

把 idna.ToASCII 的结果再 strings.ToLower 一次可以吗？

如果只是为了显示或某个明确的 ASCII 键规则，可以单独讨论，但它不能替代 Lookup Profile。对于域名查找，应直接使用查找映射，避免遗漏宽度、兼容字符和规范化处理。

为什么同一个输入在 ToASCII 和 Lookup.ToASCII 下不同？

因为前者走原始 Punycode 处理，后者先按查找规则进行映射。差异不是随机行为，而是两个 Profile 的职责不同。

注册前先转小写是不是更严格？

不是。转小写只改变字符形式，不能证明输入满足注册规则；注册场景应让 Registration 返回明确的校验结论，并保留错误信息。

最后记住一句话：ToASCII 负责表示，Lookup 负责查找前映射，Registration 负责注册校验；“看起来变成小写”从来不是 IDNA 处理完成的充分条件。