为什么 xml.Unmarshal 解析 RSS 总是返回空结构体？
根本原因通常是 XML 命名空间（Namespace）和字段标签没对上。RSS 2.0 文档里常见 <rss xmlns="http://purl.org/rss/1.0/"></rss> 或带 dc:、media: 前缀的子元素，但 go 的 xml 包默认忽略命名空间，也不会自动映射带前缀的标签。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
curl -s https://example.com/feed.xml | head -20看原始 XML，确认是否存在xmlns或命名空间前缀 - 结构体字段必须用
xml:标签显式声明，比如XMLName xml.Name `xml:"rss"`，且嵌套层级要严格匹配 - 遇到
<creator></creator>这类带前缀的字段，不能写Creator String `xml:"dc:creator"`—— Goxml包不支持前缀解析；得改用xml:",any"捕获原始子节点再手动提取 - 如果 RSS 使用 atom 命名空间（如
xmlns="http://www.w3.org/2005/Atom"），建议直接用encoding/xml解析，别强行统一成 RSS 结构体
用 http.Client 抓 RSS 时被 403 或连接重置怎么办？
RSS 源通常对 User-Agent 敏感，尤其是一些博客平台或聚合服务会拦截默认的 Go 请求头。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须设置
User-Agent，例如：req.Header.Set("User-Agent", "Mozilla/5.0 (X11; linux x86_64) golang/rss-fetcher") - 有些站点要求
Accept头为application/rss+xml,text/xml,application/atom+xml，漏掉可能返回 HTML 登录页 - 超时一定要设：
http.Client{Timeout: 10 * time.Second}，否则 DNS 卡住或服务器无响应会让整个程序挂起 - 别复用全局
http.DefaultClient：它没有超时控制，且在高并发下容易耗尽文件描述符
xml.Decoder 和 xml.Unmarshal 该选哪个？
取决于 RSS 数据规模和健壮性要求。xml.Unmarshal 简单但内存不友好；xml.Decoder 流式解析适合大 Feed 或需要提前终止的场景。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 小到中等 RSS（xml.Unmarshal，代码少、逻辑直白
- 想跳过无效条目（比如
<item></item>缺<title></title>就丢弃）、或只取前 5 条，必须用xml.Decoder配合Token()逐个读取 -
xml.Decoder默认不校验嵌套深度，恶意构造的深层嵌套 XML 可能导致栈溢出，建议调用d.Depth = 10限制（Go 1.20+ 支持） - 注意
Decoder会吃掉开头的 XML 声明（如<?xml version="1.0"?>），但不影响解析，无需额外处理
时间字段 <pubdate></pubdate> 解析失败，返回零值
RSS 的 pubDate 格式不统一：RFC 822（Mon, 02 Jan 2006 15:04:05 MST）、ISO 8601（2006-01-02T15:04:05Z）、甚至 Unix 时间戳都可能出现。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别依赖
time.RFC1123Z或单一格式；用time.Parse尝试多个布局，按优先级顺序 fallback - 字段类型别直接定义为
time.Time，先存为string，解析失败时还能记录原始值用于调试 - 注意时区：RSS 多用
GMT或UTC，但有些源写成PST，Go 的Parse对缩写时区支持有限，建议统一转成 UTC 后再存 - 如果用
xml.Unmarshal，可为该字段实现UnmarshalXML方法，把解析逻辑封装进去，避免散落在业务代码里
真正麻烦的是混合格式——同一个 Feed 里不同 <item></item> 的 pubDate 可能用两种格式。这种细节没人告诉你，但线上一跑就暴露。