单页应用不必强制使用前端路由，但放弃它就失去SPA核心体验；BrowserRouter需服务端fallback支持，HashRouter则通过URL哈希规避配置问题，二者在URL形式、兼容性和SEO上存在差异。
单页应用必须用前端路由吗？
不是必须，但不用就等于放弃单页应用的核心体验。传统 HTML 路由（即每次跳转都发请求、服务端返回完整 HTML）和单页应用（SPA）本质冲突：SPA 的目标是不刷新页面、局部更新视图，而服务端路由强制整页重载。一旦你用 create-react-app、vue-cli 或 astro dev 启动本地开发服务器，默认走的是前端路由逻辑，此时若后端没配好 fallback，直接访问 /dashboard 就会 404。
静态托管时 404 怎么破？
这是最常踩的坑——开发时一切正常，部署到 Netlify、Vercel 或 Nginx 后，刷新 /user/profile 页面直接报 404。原因很直接：这些路径在服务端根本不存在 HTML 文件，而前端路由还没来得及启动。
-
Netlify：在项目根目录加_redirects文件，写一行/* /index.html 200 -
Vercel：默认支持 SPA fallback，无需额外配置（但需确认vercel.json没误删"rewrites"） -
Nginx：在 location 块里加try_files $uri $uri/ /index.html; - GitHub Pages：不支持服务端重写，只能改用
HashRouter（路径带#），例如/#/settings
BrowserRouter 和 HashRouter 到底差在哪？
区别不在功能，而在 URL 表现和兼容性约束。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
BrowserRouter依赖 History API（pushState/replaceState），URL 干净（/about），但要求服务端配合 fallback -
HashRouter把路由存在 URL 的 hash 部分（/#about），浏览器不会把 hash 发给服务端，所以天然免配置，但 SEO 友好性差，且部分老系统或内嵌 WebView 对 hash 监听不稳定 - React Router v6.4+ 开始，
createBrowserRouter默认绑定服务端渲染逻辑，纯客户端 SPA 仍推荐createHashRouter或显式用createBrowserRouter+ 客户端 hydration
要不要在服务端也做路由判断？
要看你是否启用 SSR 或需要首屏直出。纯客户端 SPA 中，服务端路由只管一件事：把所有非静态资源请求（如 /api/）正常代理，其余全部 fallback 到 index.html。但如果你用 Next.js 或 Nuxt，服务端路由就变成关键路径——它决定哪个组件被预渲染、哪些数据在响应前就 fetch 完。这时候 getServerSideProps 或 defineEventHandler 就不是可选项，而是数据加载链的起点。
立即学习“前端免费学习笔记（深入）”；
容易被忽略的一点：即使用了 SSR，前端路由依然要接管后续导航，否则点击链接又变整页跳转。也就是说，服务端路由和前端路由不是二选一，而是分阶段协作——首次加载靠服务端，之后交互靠前端。
