Go 解析 RSS 易 panic，需显式 xml 标签、指针切片、命名空间处理；定时拉取须 goroutine 隔离、超时控制与退避重试；去重应 fallback 至 link+title 哈希；本地调试用 http.ServeFile 模拟异常 RSS。
Go 里解析 RSS XML 经常 panic，因为 xml.Unmarshal 对字段标签太敏感
Go 的 xml 包不会自动忽略缺失字段或大小写不匹配，一遇到 RSS 里常见的 <pubDate>、<dc:creator> 这类带命名空间或驼峰 / 下划线混用的字段，就直接返回 xml: unsupported type: map[string]string 或静默跳过内容。
实操建议：
立即学习 “go 语言免费学习笔记（深入）”；
- 所有结构体字段必须显式加
xml标签，比如PubDate string `xml:"pubDate"`，不能依赖首字母大写自动映射 - 嵌套元素（如
<channel>下的<item>）要用指针字段：Items []*Item `xml:"item"`，否则切片可能为空 - 遇到命名空间（如
dc:creator），用完整前缀 + 空格分隔：Creator string `xml:"dc creator"`，前提是已调用xml.NewDecoder并设置Strict = false - RSS 2.0 和 Atom 混合时，别强求单个结构体兼容——为不同格式定义独立结构体更稳
用 time.Ticker 做定时拉取 RSS，但没处理并发和错误重试会丢数据
单纯起 goroutine + for range ticker.C 看似简单，实际在超时、网络抖动、XML 解析失败时，整个 tick 就卡住或跳过，旧条目永远不更新。
实操建议：
立即学习 “go 语言免费学习笔记（深入）”；
- 每次 tick 启动新 goroutine 执行 fetch + parse，主循环绝不阻塞：
go func() { fetchFeed(url) }() - 给 HTTP 请求设硬性超时：
http.Client{Timeout: 15 * time.Second}，避免一个慢源拖垮全部 - 失败时不 panic，记录日志并按退避策略重试（比如首次 1 分钟后，再失败则 5 分钟）
- 用
sync.Map或带锁的 map 缓存每个 feed 最新lastBuildDate，避免重复插入相同条目
RSS 条目去重靠 guid 不可靠，得 fallback 到 link + title 拼接哈希
不少 RSS 源的 <guid> 是空的、重复的，或者带变参（如 ?utm_source=rss），只比对 guid 会导致同一文章反复入库。
实操建议：
立即学习 “go 语言免费学习笔记（深入）”；
- 优先用
guid，但必须先 trim 空格、统一协议（把http://强制转成https://） - 若
guid无效，拼接link（标准化后）和title（小写 + 去标点），再算sha256哈希作为唯一键 - 数据库存时加唯一索引（如 PostgreSQL 的
UNIQUE (feed_id, item_hash)），让冲突在写入层暴露，而不是应用层绕开 - 别用时间戳去重——同一秒发多篇很常见，尤其聚合源
本地开发调试 RSS 源时，别直接连线上地址，先用 http.ServeFile 模拟响应
反复请求真实 RSS 地址既慢又易被限流，而且无法控制返回内容（比如测试 malformed XML 或空 <item>）。
实操建议：
立即学习 “go 语言免费学习笔记（深入）”；
- 写个最小 server：
http.HandleFunc("/test.rss", func(w http.ResponseWriter, r *http.Request) {http.ServeFile(w, r, "fixtures/sample.rss") }) - 把各种异常 case 写成不同文件：
empty-channel.rss、broken-encoding.rss、no-guid.rss - 测试时把 feed URL 换成
http://localhost:8080/test.rss，改完文件不用重启程序 - 上线前删掉这段代码，或用 build tag 隔离：
//go:build dev
真正麻烦的是 RSS 源之间字段语义不一致——有的 pubDate 是发布时间，有的是抓取时间；有的 description 是摘要，有的是全文 HTML。这部分没法靠解析库解决，得在业务逻辑里逐个 source 配置清洗规则。
