标签与 HTTP 请求方法的关系
" />
标签本身不主动触发任何 HTTP 请求方法（如 GET/POST），其行为完全取决于 rel 属性的语义和浏览器/客户端的实现策略；仅当用于资源预加载（如 rel="preload"）时，浏览器才发起隐式 GET 请求。
`` 标签本身不主动触发任何 http 请求方法（如 get/post），其行为完全取决于 `rel` 属性的语义和浏览器/客户端的实现策略；仅当用于资源预加载（如 `rel="preload"`）时，浏览器才发起隐式 get 请求。
在 Web 开发实践中，常有人将 与 、 等标签类比，误以为它“默认发送 GET 请求”。但事实并非如此： 是一个元数据关联标签（metadata link element），核心作用是声明当前文档与外部资源之间的语义关系，而非发起网络请求。
✅ 什么情况下 会引发 HTTP 请求？
仅当 rel 属性指定了具有获取意图的预加载类关系时，现代浏览器才会主动发起 GET 请求（且仅限于该资源的实际加载阶段）：
| rel 值 | 是否触发请求 | 请求方法 | 说明 |
|---|---|---|---|
| preload | ✅ 是 | GET | 显式指示浏览器提前获取关键资源（如字体、JS、CSS），浏览器立即发起 GET 请求。 |
| prefetch | ✅ 是 | GET | 暗示“未来可能需要”，浏览器在空闲时以低优先级 GET 获取。 |
| preconnect | ✅ 是 | — | 触发 DNS 解析 + TCP/TLS 握手（无 HTTP 方法，属连接层优化）。 |
| dns-prefetch | ✅ 是 | — | 仅 DNS 查询，不涉及 HTTP 请求。 |
| stylesheet | ✅ 是 | GET | 加载 CSS 文件时，浏览器自动发起 GET 请求（这是最常见且易被忽略的隐式 GET 场景）。 |
| icon / apple-touch-icon | ✅ 是 | GET | 加载 favicon 或图标时触发 GET。 |
| canonical | ❌ 否 | — | 仅供搜索引擎解析，浏览器不发起请求。 |
| next / prev | ❌ 否 | — | 语义导航提示，不触发请求。 |
| webmention | ❌ 否（客户端侧） | POST（需脚本显式调用） | 需 JavaScript 主动构造并发送 POST 请求至目标端点， 仅提供发现机制。 |
✅ 示例：
浏览器解析到该标签后，会立即以 GET 方法 请求 /assets/main.js，并缓存结果，供后续 <script> 使用。</script>
❌ 反例：
此标签仅向搜索引擎表明规范 URL，浏览器不会向该地址发送任何 HTTP 请求——既非 GET，也非 POST。
⚠️ 关键注意事项
- 无默认方法：HTML 规范（HTML Living Standard）未为 定义任何强制性的 HTTP 方法语义。是否请求、何时请求、用什么方法请求，均由 rel 的具体含义及用户代理（浏览器）实现决定。
- rel 决定一切：不要脱离 rel 属性谈 的网络行为。同一个 标签，rel="stylesheet" 和 rel="author" 的网络影响天壤之别。
- 非资源型 rel 不触发网络活动：如 rel="help"、rel="license"、rel="me" 等纯语义关系，仅用于机器可读元数据，不产生网络请求。
- Webmention 等协议需 JS 配合：虽然 可声明接收端点，但实际通知必须由前端脚本调用 fetch(..., { method: 'POST', ... }) 完成—— 本身只是“地址牌”，不是“发信员”。
✅ 总结一句话
标签本身不绑定任何 HTTP 方法；它是否触发请求、触发何种请求（绝大多数场景下仅为 GET），完全取决于 rel 属性的标准化语义以及浏览器对该语义的实现策略。开发者应始终基于 rel 的规范定义设计预期行为，而非假设其具有类似 的导航能力。
如需主动控制请求方法（如 POST/PUT/DELETE），必须使用 JavaScript 的 fetch() 或 XMLHttpRequest——这是唯一能精确指定 HTTP 方法的客户端手段。
