后端路由在两种情况下都会被触发：用户直接访问匹配的 url，或前端通过 fetch 发起请求；但二者目的、行为和适用场景截然不同——前者用于页面跳转与 html 渲染，后者专为数据交互设计，支持完整 http 方法、自定义头、错误处理与前端逻辑集成。
在 Web 开发中，一个常见的误解是认为“只要 URL 匹配后端路由，就等同于完成了有意义的数据使用”。实际上，路由匹配只是请求触发的第一步，关键在于谁发起请求、以何种方式发起，以及后续如何处理响应。
✅ 两者都会触发后端路由，但本质不同
当你在浏览器地址栏输入 http://localhost:3000/restaurants 并回车时，浏览器会自动向服务端发送一个 GET /restaurants 请求。此时，你的 express 路由：
app.get('/restaurants', (req, res) => { res.json(ALL_RESTAURANTS); });确实会被执行，ALL_RESTAURANTS 数组也会被序列化为 json 返回。但问题在于：浏览器会把这份纯 JSON 当作响应体直接渲染成一片无格式文本页面——没有样式、没有结构、无法交互，对用户毫无友好性。
而使用 fetch 的方式：
const getRestaurants = async () => { try { const response = await fetch(`${API_ENDPOINT}/restaurants`); if (!response.ok) throw new Error(`HTTP ${response.status}`); const restaurants = await response.json(); renderRestaurantList(restaurants); // ✅ 自定义渲染逻辑 return restaurants; } catch (err) { console.error("Failed to load restaurants:", err); showErrorMessage("餐厅列表加载失败，请稍后重试"); } };不仅触发了同一后端路由，更赋予了前端完整的控制权：可校验状态码、解析 JSON、错误降级、条件渲染（如按评分过滤）、与状态管理（如 react useState / Redux）集成，甚至组合多个 API 请求。
⚠️ 导航访问 API 路由的局限性
| 能力 | 浏览器地址栏导航 | fetch / axios 等客户端请求 |
|---|---|---|
| 支持 HTTP 方法 | 仅 GET（及少数 HEAD） | GET, POST, PUT, delete, PATCH 等全方法 |
| 自定义请求头 | ❌ 不支持 | ✅ 可设置 Authorization, Content-Type, X-Request-ID 等 |
| 请求体（JSON/form） | ❌ 无法发送 body | ✅ fetch(url, { method: ‘POST’, body: JSON.stringify(…) }) |
| 预检请求（CORS Preflight） | ❌ 不触发 | ✅ POST 带 Content-Type: application/json 会自动触发 |
| cookie 自动携带 | ✅（同源且 credentials: ‘include’ 默认启用） | ✅ 但需显式配置 credentials: ‘include’ |
| 响应处理灵活性 | ❌ 仅能展示原始响应（html/JSON/文本） | ✅ 可解析、转换、缓存、合并、节流、重试 |
? 补充说明：若后端未正确配置 CORS（如缺少 access-Control-Allow-Origin），即使 fetch 请求成功发出，浏览器也会因安全策略拦截响应体，导致前端报错 TypeError: Failed to fetch —— 这恰恰体现了 fetch 的“可控性”：它暴露问题，而导航则可能静默失败（如返回空白页）。
✅ 正确分工：路由 ≠ 页面，API ≠ 展示
- 后端路由 /restaurants 是一个数据端点（API endpoint），职责是安全、可靠、结构化地提供数据，不负责呈现。
- 前端负责消费该数据：用 fetch 获取 → 校验 → 解析 → 存入状态 → 渲染 ui → 处理加载/错误态。
- 若你真想“通过 URL 访问餐厅列表”，正确做法是：
- 后端提供一个 HTML 页面路由（如 GET /restaurants-page），返回含
- 列表的完整 HTML；
- 或采用 服务端渲染（SSR）/静态生成（SSG），如 Next.js 的 getServerSideProps，在服务端调用 /restaurants API 并注入数据后返回 HTML。
- 后端提供一个 HTML 页面路由（如 GET /restaurants-page），返回含
? 总结
不是“要不要用 fetch”，而是“何时该用导航，何时该用 API 调用”。
- 导航（URL 输入/）适用于页面级跳转（如 /login, /profile），目标是加载新 HTML 文档；
- fetch 适用于数据驱动交互（如加载列表、提交表单、点赞、搜索），目标是获取结构化数据并交由前端逻辑处理。
把 API 路由当作“仅供程序调用的接口”，而非“给用户看的网页”，是构建现代 Web 应用的关键认知分水岭。