不能用字符串切分，因为url结构复杂且受rfc 3986约束：://不一定在首个冒号后，host可能含端口、ipv6地址或用户信息，手动切分易漏case或误判。
直接用 url.Parse 解析，再取 URL.Scheme 和 URL.Host 字段即可——但要注意空 Scheme、端口混入 Host、以及不带 Schema 的相对 URL 会失败。
为什么不能用字符串切分（如 strings.Split）？
URL 的结构有规范约束：:// 不一定出现在第 1 个冒号后（比如 mailto:user@example.com），Host 可能含端口（example.com:8080）、IPv6 地址（[::1]:3000），甚至带用户信息（user:pass@host）。手动切分极易漏 case 或误判。
常见错误现象：
– 把 https://api.example.com/v1 的 Host 错切成 api.example.com/v1
– 把 http://[::1]:8080 的 Host 错当成 [::1]:8080 以外的字符串
– 遇到 //cdn.example.com/logo.png（协议相对 URL）直接 panic
url.Parse 的正确用法与边界处理
url.Parse 是标准库中唯一可靠的方式。它返回一个 *url.URL，其 Scheme 和 Host 字段已按 RFC 3986 规范归一化。
- 如果输入不含 Scheme（如
//example.com或/path），Parse会返回 error，URL.Scheme为空字符串 -
URL.Host包含端口（如果有），例如example.com:443；若需纯域名，得用url.ParseHost或手动剥离端口 - IPv6 Host 会被包裹在方括号里，
URL.Host保持原样（如[::1]:3000），这是合法且预期行为
示例：
u, err := url.Parse("https://user:pass@[::1]:8080/path?k=v#frag")
if err != nil {
log.Fatal(err)
}
fmt.Println(u.Scheme) // "https"
fmt.Println(u.Host) // "[::1]:8080"
提取纯 Host（不含端口）的稳妥做法
很多场景需要的是「域名」而非完整 Host，比如做白名单校验或路由分发。不能简单 strings.Split(u.Host, ":")，因为 IPv6 Host 本身含冒号。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
标准库提供了 url.SplitHostPort，它能正确识别并分离 IPv6 Host 中的端口：
- 对
example.com:8080→ 返回"example.com"和"8080" - 对
[::1]:3000→ 返回"[::1]"和"3000" - 对
example.com（无端口）→ 返回"example.com"和 error（可用err == nil判断）
所以安全提取纯 Host 的写法是：
host := u.Host
if port := u.Port(); port != "" {
if h, err := url.SplitHostPort(u.Host); err == nil {
host = h
}
}
// host 现在是去端口后的结果
注意：u.Port() 是便捷方法，等价于解析 u.Host 中的端口部分，但它不校验格式；真正健壮的分离仍要靠 url.SplitHostPort。
容易被忽略的点：相对 URL 和空 Scheme 的处理
如果你的输入可能来自 HTML href、API 响应字段或用户输入，大概率遇到不带 Scheme 的 URL，比如：
-
//cdn.example.com/asset.js（协议相对） -
/api/users（路径相对） -
example.com（纯 Host，非 URL）
这些调用 url.Parse 都会失败或返回空 Scheme。不要假设输入一定是绝对 URL——加一层预处理：检测是否以 :// 结尾前缀，或手动补 https:// 再解析（仅当业务允许默认协议时）。
最保险的做法是明确区分输入类型：如果是 HTTP 客户端请求地址，通常要求绝对 URL；如果是配置项或前端传参，必须文档化约定格式，并在代码中校验 u.Scheme != ""。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
