企业官网建设流程全解析

React 生态里有一个绕不开的话题，就是路由。不管你是刚接触组件化开发，还是已经写过一段时间业务代码，只要涉及到多页面、多视图切换，路由就是那根承重墙。我这次分享的是 React Router v4（也就是标题里说的 router 4），它和我早期折腾过的 v3 完全是两种思路，可以说是一套重新定义“路由到底是什么”的方案。这篇文章我会从设计理念、核心 API、实际落地到踩坑记录，把 router 4 彻底掰开揉碎讲清楚。适合正在学 React、准备面试、或者想把项目路由从“能跑”升级到“规范”的开发者。

先说为什么单独把 router 4 拎出来讲。v4 是 React Router 历史上一次近乎推倒重来的版本，它把路由从“配置式”彻底转向“组件化”。很多老项目里的<Route path="/" component={Home} />写法看似没变，但底层机制、嵌套逻辑、传参方式全变了。如果你拿着 v3 的思路去写 v4，碰到的第一个问题就是“为什么路由不生效”或者“为什么组件重复渲染”。反过来，如果你一步到位直接学 v4，理解组件化路由的心智模型，后面再去看新版 React Router（v6）几乎就是降维打击，因为 v6 的很多设计正是在 v4 的基础上进一步简化的。

1. React Router v4 到底改了什么：从版本变迁看设计哲学

1.1 从“路由配置”到“组件即路由”的跨越

在 React Router v3 时代，整个路由更像一张集中式的配置表：你在一个地方声明所有路径规则，然后 React Router 根据当前 URL 去匹配对应的组件。这种方式很像后端的路由表，优点是清晰、集中、好审查，缺点是很笨重——你想做动态的、根据状态变化的嵌套路由，得在配置表里写大量条件判断，而且组件和路由的关联是隐式的，代码跳来跳去非常痛苦。

v4 的核心变化是“路由不再是配置，而是一个组件”。你不再需要把路由规则集中到一个地方，而是在组件树里的任何位置直接放<Route>。组件树有多深，路由就可以嵌套多深。路由规则和组件层级天然对应，你在哪个组件内部声明<Route>，它匹配到的子组件就渲染在哪个位置。这种设计直接对标的是“组件化思维”——路由只是 UI 的一部分，它和普通组件一样可以组合、可以嵌套、可以根据 props 变化重新渲染。

当时我接手一个中型后台管理系统，老代码用的是 v3，每次新增页面都得去改一长串路由配置文件，页面之间跳转还要手写路径字符串。切到 v4 之后，每个模块直接在自身组件里声明子路由，模块删除时连根拔起，不会再有“删了个页面结果路由配置里残留一堆死路径”的问题。这种解耦带来的维护性提升是实打实的。

1.2 “一切皆组件”的心智模型

v4 让你用 React 的方式而不是“路由框架”的方式思考。它把 decodeURIComponent、history 监听、location 匹配这些底层逻辑全部封装进<Router>容器，暴露给你的是一套声明式组件：<Route>、<Link>、<Switch>、<Redirect>。每个组件只干一件事，组合起来就是完整路由方案。

我用一个生活化类比来帮助你理解：v3 的路由像一张纸质地图，你查好路线照着走；v4 的路由像车上的导航播报，你只需要告诉它“去这里”，它会在组件树里实时告诉你当前该显示哪一块内容。你的注意力从“路线图长什么样”转移到“当前这个路口该显示什么组件”。

这种心智模型的转变，直接影响后续所有 React 路由方案的设计。现在很多人直接上手 v6，觉得useRoutes和嵌套路由很自然，其实很多概念在 v4 时就已经定型了。学 v4 不是学“过时的老古董”，而是掌握路由组件化的根。

2. 核心 API 逐个拆解：这些组件到底怎么用

2.1 BrowserRouter、HashRouter 与 MemoryRouter 的取舍

v4 把底层路由容器拆成了三个：BrowserRouter、HashRouter、MemoryRouter。很多新手搞不清区别，实际使用中选错就会出问题。

BrowserRouter 使用 HTML5 History API（pushState、replaceState、popstate），URL 是干净的路径形式，比如/user/123。这是“正规军”打法，适合绝大多数 Web 应用。但它有一个硬性前提：服务器必须把所有前端路由路径都重定向到 index.html。否则用户直接访问/user/123会得到 404。

HashRouter 使用 URL 的 hash 部分（#/user/123）来模拟路由跳转。它的优势是服务器完全不用配置，任何静态文件服务器都能跑，适合纯静态演示页或简易内部工具。缺点是 URL 丑、SEO 差、hash 部分无法被服务器识别。我个人的经验是：除非你托管环境受限，否则尽量用 BrowserRouter，后面我会说怎么配置服务器来支持它。

MemoryRouter 则是把路由状态保存在内存里，地址栏完全不变。这个在浏览器里几乎不用，但在 React Native 或测试环境里非常有用——你要写单元测试时，MemoryRouter 能让你脱离浏览器环境渲染组件树。

2.2 Route 组件的三种渲染方式，你选哪种

<Route>是 v4 的核心组件，它的 props 可以写<Route path="/about" component={About} />这样，但这里有几个坑。

第一种是component方式。它直接用React.createElement创建组件，每次渲染都会创建新实例。如果你在路由组件上绑定一个内联的普通函数作为 props，会导致频繁挂载卸载。我见过一个项目在component属性里写component={props => <MyComp {...props} />}，结果每次父组件状态一变，路由页面就重新挂载，表单输入框里的值全没了。

第二种是render方式。它接收一个函数，由你手动控制渲染内容。这种方式更灵活，适合在匹配到路由时做一点包装或传参。官方推荐：需要传自定义 props 时用render而不是component。

第三种是children方式。它不管路径是否匹配都会渲染，接收的 props 里有一个match字段，你可以根据match === null来判断当前路由是否激活。这种用法比较少，但在做一些“始终显示、但内容随路径变化”的布局容器时很好用。

我实际使用中的经验是：80% 的场景直接用component就好，把组件定义成正常的类组件或函数组件；遇到需要传额外 props 的时候换成render；children用在侧边栏高亮、面包屑这类场景。别一上来就render，过度设计也是坑。

2.3 Link、NavLink、Switch、Redirect：路由跳转的四件套

<Link>是声明式的跳转入口，它最终渲染成<a>标签，但内部拦截了默认跳转行为，通过 history API 完成页面切换。注意：Link必须位于Router容器内部，否则会报错“You should not use Link outside a Router”。

NavLink是Link的升级版，它支持activeClassName和activeStyle，在匹配到当前路径时自动高亮。我经常用它做导航菜单，配合exact属性控制精确匹配。举个例子：导航里有/products和/products/123，如果你只希望/products在列表页时高亮，就需要给NavLink加exact，否则进入详情页时列表导航依然亮着。

<Switch>的出现解决了“多个 Route 同时匹配”的问题。v4 中Route是允许并行匹配的，如果你写了/about和/:id两条路由，访问/about时两个都会渲染。Switch会遍历子Route，只渲染第一个匹配到的。我把Switch当作路由表的“唯一出口”使用：一组并列路由全部套进Switch，最后一个兜底用Redirect重定向到首页或 404 页。

<Redirect>是路由重定向组件。它有两种用法：一是静态重定向，比如访问/home时直接跳到/；二是条件重定向，比如“未登录就跳到登录页”。后者是路由守卫的核心实现方式，后面我会展开讲。

2.4 withRouter 高阶组件：让普通组件拿到路由三件套

v4 中，Route、Link这些组件内部能拿到 history、location、match，但普通子组件如果需要操作路由跳转，就得靠withRouter包一层。它本质上是一个高阶组件，把路由相关的三个 props（history、location、match）注入到被包裹的组件上。

我遇到过不少新手问：为什么我这个组件里this.props.history是 undefined？原因很简单——这个组件不是被<Route>直接渲染的，而是被某个普通父组件引用的，它根本不在路由上下文中。解决办法就是导出时用withRouter(MyComponent)包一层。

后来 React Router 推出了useHistory、useLocation、useParams这些 hooks，函数组件里不再需要withRouter。但如果你的项目还在用类组件，withRouter仍然是必需工具。即便已经切换到函数组件，理解withRouter仍然有助于理解 hooks 版本背后的机制。

3. 从零搭建一套靠谱的路由方案：完整实操

3.1 环境准备：版本选择与安装细节

我用 React Router v4 做演示，安装时要注意版本标签。在 package.json 里指定react-router-dom: ^4.3.1，不要直接npm install react-router-dom装出 v6。如果你用的是 Vite 或 CRA 脚手架，安装命令如下：

npm install react-router-dom@4.3.1 npm install react-router@4.3.1

注意：react-router-dom是给浏览器环境用的包，它内部依赖react-router。实际项目中只需要安装react-router-dom，它会自动带上react-router。像 React Native 环境才需要react-router-native。装了react-router-dom就不要单独再装react-router，版本不一致会导致“Duplicate module”之类的问题。

创建 React 应用不是本文重点，我用的是 create-react-app 生成的默认项目，把所有无关文件清掉，只保留核心入口。下面这段代码演示了最基本的 BrowserRouter 用法：

import React from 'react'; import ReactDOM from 'react-dom'; import { BrowserRouter, Route, Switch, Link } from 'react-router-dom'; const Home = () => <div>首页</div>; const About = () => <div>关于我们</div>; const NotFound = () => <div>404</div>; function App() { return ( <BrowserRouter> <nav> <Link to="/">首页</Link> | <Link to="/about">关于</Link> </nav> <Switch> <Route exact path="/" component={Home} /> <Route path="/about" component={About} /> <Route component={NotFound} /> </Switch> </BrowserRouter> ); } ReactDOM.render(<App />, document.getElementById('root'));

这段代码里有几个关键点，我逐一解释一下。

exact属性非常重要。如果不写exact，/about路径在匹配/about/123、/about/abc时都会命中，而访问/时因为它是所有路径的前缀，也会命中根路由。如果你希望根路由只在 URL 完全等于/时显示，必须加exact。

最后一个<Route component={NotFound} />没有path，它会匹配所有路径。配合Switch的“只渲染第一个匹配”的特性，这实际上是实现 404 页面的标准写法。访问一个不存在的路径时，前两个Route都不匹配，最后一个无路径Route生效。

这种写法很简单，但已经能跑通“多页面跳转 + 重定向 + 404”的核心链路。很多小博客、个人作品集就够用了。

3.2 嵌套路由与动态传参：后台管理系统的地基

真实项目的路由不会这么简单。拿后台管理系统举例，通常会有布局结构：顶部导航 + 左侧菜单 + 右侧内容区。你想在内容区里再嵌套路由，让/admin/user/list对应“用户列表”，/admin/user/detail/:id对应“用户详情”。

v4 里嵌套路由的写法是在父组件内部再写Route，而不是在顶层把所有规则铺平。父组件需要接收match对象，然后基于match.url拼接子路径。

const UserLayout = ({ match }) => { return ( <div> <h2>用户管理</h2> <nav> <Link to={`${match.url}/list`}>用户列表</Link> <Link to={`${match.url}/detail/001`}>查看001</Link> </nav> <Route exact path={`${match.url}/list`} component={UserList} /> <Route path={`${match.url}/detail/:id`} component={UserDetail} /> </div> ); };

这里match.url是当前已匹配到的 URL 前缀。如果父路由是path="/admin/user"，那么match.url就是/admin/user。用模板字符串拼接子路径是 v4 推荐的做法，别硬编码绝对路径，否则父路由路径一旦变化，子路由全崩。

动态参数:id会作为match.params.id传入子组件。UserDetail组件里这样读取：

const UserDetail = ({ match }) => { return <div>当前用户ID：{match.params.id}</div>; };

也可以更优雅地解构：const { id } = match.params;。这种方式在列表跳详情、编辑页回显等场景非常常见。我当时做的一个订单系统，列表点击“查看详情”就是通过history.push('/order/detail/' + orderId)跳转，然后详情页通过match.params.id发请求拉取数据。

3.3 路由守卫与权限控制：自己动手写一个 PrivateRoute

React Router v4 官方没有内置“路由守卫”这种概念，但我们可以用组件包装来实现。最常见的需求是：未登录用户访问需要权限的页面时，重定向到登录页。

我封装一个PrivateRoute组件：

import React from 'react'; import { Route, Redirect } from 'react-router-dom'; function PrivateRoute({ component: Component, isAuthenticated, ...rest }) { return ( <Route {...rest} render={(props) => isAuthenticated ? ( <Component {...props} /> ) : ( <Redirect to={{ pathname: '/login', state: { from: props.location } }} /> ) } /> ); }

用法：

<Switch> <Route path="/login" component={Login} /> <PrivateRoute path="/dashboard" isAuthenticated={isLoggedIn} component={Dashboard} /> </Switch>

这里有几个细节值得说明。

render的返回值是一个组件渲染结果。当isAuthenticated为 true 时渲染目标页面；为 false 时渲染Redirect。Redirect的to可以是一个对象，state.from记录用户原本想去的路径，登录成功后可以用history.replace(state.from)跳回原页面，这个体验是很多产品都有的“登录后回跳”。

PrivateRoute里的...rest会把多余的 props（如path、exact）传给Route。component被我重命名成Component，因为我们要手动渲染它，不能直接放在 props 里交给Route。

这种模式也可以扩展成GuestRoute（已登录用户访问登录页时跳回首页）、RoleRoute（基于角色判断是否有权访问）。路由守卫的本质就是用render做一层条件拦截，把权限逻辑从页面组件里剥离出来。我在多个项目里复用这套代码，几乎零改动。

3.4 懒加载与代码分割：让首屏加载不再臃肿

单页应用最大的痛点之一是首屏 JS 体积过大。路由拆分天然是代码分割的切入点。v4 + React 16 可以配合React.lazy和Suspense实现按路由懒加载，让每个路由的组件代码独立打包，访问时才加载。

import React, { Suspense, lazy } from 'react'; import { BrowserRouter, Route, Switch } from 'react-router-dom'; const Home = lazy(() => import('./pages/Home')); const About = lazy(() => import('./pages/About')); function App() { return ( <BrowserRouter> <Suspense fallback={<div>页面加载中...</div>}> <Switch> <Route exact path="/" component={Home} /> <Route path="/about" component={About} /> </Switch> </Suspense> </BrowserRouter> ); }

lazy(() => import('./pages/Home'))会把Home组件单独拆成一个 chunk。Suspense的fallback是加载过程中展示的占位内容。注意Suspense必须包裹所有可能懒加载的子组件，通常放在Switch外层最省事。

这段代码虽然用了新的 React API，但和 router 4 是兼容的，实践下来很稳。如果你用的是 React 18 的环境，直接套用也无压力，React 版本向前兼容。

首屏体积的优化效果是立竿见影的。我做过一个管理后台，全量打包的 JS 有 5MB（包含图表库、富文本编辑器），路由懒加载之后首屏降到不到 1.5MB，加载速度至少提升一半。如果你用 webpack，还可以结合 SplitChunksPlugin 把公共依赖单独缓存，这里就不展开了。

4. 实战中的坑：常见问题与排查技巧实录

4.1 刷新后 404 的问题，服务器到底怎么配

BrowserRouter 的常见坑：本地开发一切正常，部署到服务器后，用户在/about页面刷新就 404。“为什么开发环境没事”是因为 webpack 的 devServer 默认支持 historyApiFallback，它会把请求都重写到 index.html。生产环境没有这个机制。

我之前用 Nginx 部署 React 应用，配置如下：

server { listen 80; server_name example.com; root /var/www/myapp; index index.html; location / { try_files $uri $uri/ /index.html; } }

关键就是try_files $uri $uri/ /index.html，它把所有找不到的路径都回退到 index.html，让前端路由脚本去解析。注意静态资源（比如/static/js/main.js）会先尝试匹配$uri，找到真实文件就直接返回，不会回退。

如果你用的是 Apache、Node.js（Express）或任意云托管平台（比如 Vercel、Netlify），思路都一样：识别前端路由并指向 index.html。Express 的话，加一个 app.get('*', (req, res) => res.sendFile('index.html')) 兜底即可。这块配置还好，不算深坑，但确实新手必踩。

4.2 为什么我的 Route 渲染了两次

这是 v4 一个很经典的问题。我遇到过的场景：一个组件被两个 Route 匹配到。比如你写<Route path="/user" component={User} />和<Route path="/user/:id" component={User} />，访问/user/123时两个 Route 都命中，页面就会渲染两个 User。

解决办法是使用Switch。Switch会遍历其内部的Route，只渲染第一个路径匹配的。访问/user/123时，它先匹配到path="/user"的 Route（在Switch内部会先看第一个），如果第一个写的是/user，那它会把/user/123也匹配上。所以顺序很重要：把更具体的路由写在前面。

我个人的写法习惯是：静态路径优先，动态参数其次；通配兜底放最后。比如：

<Switch> <Route exact path="/user/create" component={CreateUser} /> <Route path="/user/:id" component={UserDetail} /> <Route path="/user" component={UserList} /> </Switch>

这样/user/create先精确匹配，不会落入/:id的陷阱。这种排列是 v4 时期每个 React 开发者都必须掌握的直觉。

4.3 withRouter 获取不到 history？检查你的导出姿势

类组件里withRouter的报错通常来自导出时包错了层级。我见过这种代码：

export default withRouter(connect(mapStateToProps, mapDispatchToProps)(MyComponent));

这样写其实没问题，但要注意顺序。connect 和 withRouter 的包裹先后会影响MyComponent内部能否拿到路由 props。如果你在connect外层包withRouter，那么connect的mapStateToProps里拿不到路由 props；如果你在connect内部包，则组件内部可以同时拿到 redux props 和路由 props。经验公式是：

export default withRouter(connect(mapStateToProps)(MyComponent));

这样MyComponent内部既能用this.props.history，也能用this.props.userInfo。如果顺序反了，你会在“connect 返回值”这个中间层拿到路由 props，但真正渲染的MyComponent接收的 props 里没有 history。

React 16.8 之后我建议新代码一律用函数组件加useHistoryuseParams，彻底规避这个顺序问题，但类组件存量代码依然需要 withRouter，掌握包裹顺序还是很有必要的。

4.4 动态参数变了，页面数据不刷新

访问/user/001后再点击/user/002，地址栏变了，但页面内容还是 001 的数据。这是 v4 的一个典型问题：Route复用了同一个组件实例，component属性没有变化，所以组件的componentDidMount不会再次触发。

解决方案是在组件内部监听路由参数变化。类组件用componentDidUpdate：

componentDidUpdate(prevProps) { if (prevProps.match.params.id !== this.props.match.params.id) { this.fetchData(this.props.match.params.id); } }

函数组件用useEffect依赖 params：

const { id } = useParams(); useEffect(() => { fetchData(id); }, [id]);

我一再强调，这是“详情页路由不刷新”的根因。很多新手以为是页面缓存了，其实是生命周期没触发。理解了这一点，再配合路由参数监听，就很容易解决。

4.5 v4 迁移到 v6 的兼容注意事项

虽然这篇文章主要讲 v4，但我还是想提一嘴。如果你要迁移到新版本 React Router（v6），v4 的很多 API 都会被移除：Switch变成了Routes；component/render合并成element；useHistory变成useNavigate；Redirect变成Navigate。这是一个“新框架”级别的迁移，不是简单的依赖升级。

我在迁移一个项目时花了两天处理路由参数传递差异。v6 的动态路由从/user/:id变成/user/:id但获取方式变了，嵌套路由也从“组件内部写 Route”变成“父路由的 Outlet”。整体上 v6 的规格更统一，但如果你的组件代码里大量依赖match.url和withRouter，迁移成本不低。建议只改必要页面，不要一次性推翻。

5. 讲一点我的真实体会

React Router v4 最值得学习的点是它把路由这个“系统级概念”拉回到了组件思维里。以前你写路由要面向配置、面向路径、面向规则；现在你面向的是组件和组合。这种方式让路由和业务代码的耦合度更低，也让“组件可复用性”这一 React 核心优势扩展到了路由层。

我在这几年的实际项目里，从一开始被 v4 的嵌套路由绕晕，到后来可以闭着眼写 PrivateRoute，再到能精准定位“刷新 404”和“路由重复渲染”的根因，最大的感悟就是：路由不是一次性配置完就结束的东西，它会随着业务的增长不断膨胀。你一开始写得好，后边维护就是享受；一开始图省事把路由全部堆在 App.js 里，后期随便加一个模块都要小心翼翼。

给正在学 React 的朋友一个建议：别急着用 v6，先拿 v4 练手，手写一遍 Switch 匹配逻辑、手写一遍 PrivateRoute、手写一遍嵌套路由。这些基本功练扎实了，任何新版路由库在你眼里都是换汤不换药。路由这件事，本质上就是把 URL 变化映射到 UI 状态的过程，理解了这一层，版本之间的 API 差异只是工具更新而已。