rel="alternate"本身不表示rss，必须搭配type="application/rss+xml"才被识别；href需为根相对或绝对路径，且rss文件须返回200状态码与正确content-type。
rel="alternate" 本身不表示 RSS，必须搭配 type 属性
很多人以为写 <link rel="alternate"> 就能自动被 RSS 阅读器识别，其实不是。浏览器和聚合器只认 rel="alternate" + type="application/rss+xml"（或 application/atom+xml）这个组合。缺一不可。
常见错误是漏掉 type，或者写成 text/xml、application/xml 这类泛型 MIME 类型——这些不会被主流阅读器（如 Feedly、Inoreader、Safari 订阅栏）当作 RSS 源处理。
-
type必须精确：RSS 用application/rss+xml，Atom 用application/atom+xml -
href必须是绝对路径或根相对路径（如/feed.xml），避免协议相对路径（//example.com/feed.xml）——部分阅读器解析失败 - 建议加
title属性，例如title="RSS feed"，某些客户端会显示该文本作为订阅项名称
多个 feed 怎么共存？用不同的 title 和 type 区分
一个页面可以同时提供 RSS 和 Atom，甚至不同语言/分类的 feed。关键靠 title 和 type 组合区分，而不是靠多个 rel="alternate" —— 它们都是合法的，且会被各自支持的客户端独立发现。
例如博客首页可这样写：
<link rel="alternate" type="application/rss+xml" title="最新文章（RSS）" href="/feed.rss"><link rel="alternate" type="application/atom+xml" title="最新文章（Atom）" href="/feed.atom"><link rel="alternate" type="application/rss+xml" title="前端专栏（RSS）" href="/category/frontend/feed.rss">
注意：title 不只是给人看的，Feedly 等工具会把它当作订阅源名称；同一 type 下重复定义（比如两个 application/rss+xml）可能导致客户端只取第一个，行为不一致。
怎么验证是否生效？别只靠“查看源代码”
写完 HTML 后，不能只检查源码里有没有那行 <link>。真正要验证的是：目标 feed 文件能否被正确访问，且响应头包含 Content-Type: application/rss+xml（或对应类型）。
- 直接在浏览器访问
href地址（如https://yoursite.com/feed.rss），看是否返回 XML 内容，且开头有<?xml version="1.0" encoding="UTF-8"?><rss> 或 <code><?xml version="1.0" encoding="UTF-8"?><feed></feed> - 用 curl 查响应头：
curl -I https://yoursite.com/feed.rss，确认包含Content-Type: application/rss+xml - 用在线工具如 W3C Feed Validation Service 检查 feed 格式合法性
Chrome 和 Safari 对 rel="alternate" 的支持现状
现代 Chrome 已完全移除地址栏 RSS 图标支持（2022 年起），Safari 也仅在特定条件下（如页面含有效 rel="alternate" + type，且用户手动触发“分享 > 订阅 RSS”）才暴露入口。也就是说：它主要服务第三方阅读器自动发现，而非浏览器原生 UI。
这意味着你不能依赖用户“看到小图标点一下”来完成订阅；实际作用是让 Feedly、Inoreader、NetNewsWire 等工具在抓取页面时自动提取 feed 地址。所以重点是确保 link 标签位置在 内、属性完整、feed 可公开访问且响应头正确——其余交给聚合器。
最容易被忽略的是服务器配置：Nginx/Apache 要为 .rss 或 .xml 后缀返回正确的 Content-Type，否则即使 HTML 写对了，feed 也会被当作普通文本加载失败。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
