后端路由在 url 匹配路径时即被触发，无论请求来自浏览器直接导航还是前端 fetch；但二者目的、行为和适用场景截然不同：导航用于页面跳转与 html 渲染，fetch 用于程序化数据交互与动态 ui 更新。
后端路由（如 Express 中的 app.get('/restaurants', ...)）本质上是服务器对符合特定 HTTP 方法 + 路径规则的请求的响应逻辑。只要客户端（无论是浏览器、curl 还是 JavaScript 的 fetch）发起一个匹配该路径的 GET 请求，服务端就会执行对应路由处理函数——它不关心请求“怎么来”，只关注“是否匹配”。
✅ 导航到 /restaurants 确实会触发路由，但结果通常不可用
当你在浏览器地址栏输入 http://localhost:3000/restaurants 并回车，浏览器确实向服务端发送了 GET 请求，服务端也正确返回了 JSON 数据（如 ALL_RESTAURANTS 数组）。但此时：
- 浏览器默认将响应体作为纯文本/JSON 文档展示（类似打开一个 .json 文件），没有 HTML 结构、无样式、无交互；
- 用户看到的是原始 JSON 字符串，难以阅读，更无法点击、筛选或分页；
- 无法携带自定义请求头（如 Authorization）、无法发送请求体（如 POST 表单数据）、无法处理错误状态码并优雅降级。
// 浏览器直接访问 /restaurants 时可能显示（不友好）：
[
{"id":"0b65fe74-...","name":"Taco Express"},
{"id":"869c848c-...","name":"Pho Vinason"}
]✅ fetch 是为应用逻辑而生的数据获取方式
前端调用 fetch('/restaurants') 同样触发同一后端路由，但关键差异在于控制权回到 JavaScript：
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();
// ✅ 动态渲染：插入到 DOM 列表中
renderRestaurantList(restaurants);
// ✅ 条件处理：仅显示评分 > 4 的餐厅
const topRated = restaurants.filter(r => r.rating && r.rating > 4);
// ✅ 错误捕获：网络失败、解析异常、空数组等均可统一处理
return restaurants;
} catch (err) {
console.error("加载餐厅列表失败：", err);
showErrorMessage("暂无法获取餐厅信息，请稍后重试");
}
};⚠️ 重要注意事项
- CORS 限制：若前端部署在 https://myapp.com，而后端在 http://localhost:3000，浏览器会因跨域策略阻止 fetch 请求（除非后端显式配置 Access-Control-Allow-Origin）；但直接导航不受 CORS 限制（因为不是“跨域资源共享”，而是用户主动跳转）。
- HTTP 方法局限：仅靠 URL 导航只能发起 GET 请求；而 fetch 可轻松支持 POST、PUT、DELETE 等，实现创建、更新、删除资源。
- SEO 与首屏体验：服务端渲染（SSR）或静态生成（SSG）中，初始 HTML 可能已内联关键数据；但 SPA 应用依赖 fetch 在客户端按需拉取，提升交互灵活性。
✅ 总结：不是“要不要触发”，而是“如何使用”
后端路由是守门人，匹配即执行； 浏览器导航是“用户视角”的请求入口，适合跳转页面；fetch 是“程序视角”的数据管道，负责驱动动态界面、处理业务逻辑、保障用户体验。 二者协同工作——路由提供能力，fetch（或 Axios 等）赋予前端调度该能力的自由度。
