_{查看对已接受答案的评论以及此问题的一般性质（“不起作用”），我认为这可能是对此处涉及的问题进行一些一般性解释的好地方。因此，此答案旨在作为 OP 特定用例的背景信息/详细说明。请多多包涵。}

服务器端 vs 客户端

首先要了解的是，现在有 2 个地方可以解释 URL，而在“过去”中，过去只有 1 个地方。过去，生活简单的时候，一些用户向http://example.com/about服务器发送请求，服务器检查 URL 的路径部分，确定用户请求的是关于页面，然后返回该页面。

使用 React-Router 提供的客户端路由，事情就不那么简单了。首先，客户端还没有加载任何 JS 代码。因此，第一个请求将始终发送到服务器。然后将返回一个页面，其中包含加载 React 和 React Router 等所需的脚本标签。只有当这些脚本加载后，阶段 2 才会开始。在第 2 阶段，例如，当用户单击“关于我们”导航链接时，URL仅在本地更改为http://example.com/about（通过History API 实现），但不会向服务器发出请求. 相反，React Router 在客户端做它的事情，决定渲染哪个 React 视图，然后渲染它。假设您的关于页面不需要进行任何 REST 调用，它已经完成了。您已从主页转换到关于我们，而没有触发任何服务器请求。

所以基本上当你点击一个链接时，一些 Javascript 会运行来操作地址栏中的 URL，而不会导致页面刷新，这反过来会导致 React Router在客户端执行页面转换。

但是现在考虑如果您将 URL 复制粘贴到地址栏中并将其通过电子邮件发送给朋友会发生什么。您的朋友尚未加载您的网站。也就是说，她还处于第一阶段。她的机器上还没有运行 React Router。所以，她的浏览器将使服务器的请求来http://example.com/about。

这就是你的麻烦开始的地方。到目前为止，您只需在服务器的 webroot 中放置一个静态 HTML 即可。但是，当从服务器请求时404，所有其他 URL都会出错。这些相同的 URL在客户端运行良好，因为 React Router 正在为你做路由，但它们在服务器端失败，除非你让你的服务器理解它们。

结合服务器端和客户端路由

如果您希望http://example.com/aboutURL 在服务器端和客户端都工作，则需要在服务器端和客户端为其设置路由。有道理吗？

这就是您的选择开始的地方。解决方案的范围从完全绕过问题，通过返回引导 HTML 的包罗万象的路由，到服务器和客户端运行相同 JS 代码的完全同构方法。

.

完全绕过问题：哈希历史

使用Hash History而不是Browser History，关于页面的 URL 将如下所示： http://example.com/#/about 哈希 ( #) 符号后面的部分不会发送到服务器。所以服务器只能http://example.com/按预期看到和发送索引页面。React-Router 将拿起#/about零件并显示正确的页面。

缺点：

• “丑陋”的网址
• 这种方法无法实现服务器端渲染。就搜索引擎优化 (SEO) 而言，您的网站由一个页面组成，上面几乎没有任何内容。

.

包罗万象

使用这种方法，您确实使用了浏览器历史记录，但只需在发送/*到的服务器上设置一个包罗万象的功能index.html，有效地为您提供与哈希历史记录大致相同的情况。但是，您确实有干净的 URL，以后可以改进此方案，而不必使所有用户的收藏夹失效。

缺点：

• 设置更复杂
• 仍然没有好的SEO

.

杂交种

在混合方法中，您可以通过为特定路由添加特定脚本来扩展包罗万象的场景。您可以编写一些简单的 PHP 脚本来返回包含内容的站点中最重要的页面，这样 Googlebot 至少可以看到您页面上的内容。

缺点：

• 设置更复杂
• 对于您给予特殊待遇的那些路线，只有良好的 SEO
• 复制用于在服务器和客户端上呈现内容的代码

.

同构

如果我们使用 Node JS 作为我们的服务器，这样我们就可以在两端运行相同的JS 代码呢？现在，我们在单个 react-router 配置中定义了所有路由，我们不需要复制渲染代码。可以这么说，这就是“圣杯”。如果页面转换发生在客户端，服务器会发送与我们最终得到的完全相同的标记。该解决方案在 SEO 方面是最佳的。

缺点：

• 服务器必须（能够）运行 JS。我已经尝试过 Java icw Nashorn，但它对我不起作用。实际上，这主要意味着您必须使用基于 Node JS 的服务器。
• 许多棘手的环境问题（window在服务器端使用等）
• 陡峭的学习曲线

.

我应该使用哪个？

选择一个你可以逃脱的。就我个人而言，我认为全能设置足够简单，所以这将是我的最低要求。此设置可让您随着时间的推移不断改进。如果你已经在使用 Node JS 作为你的服务器平台，我肯定会研究做一个同构应用程序。是的，一开始很难，但是一旦掌握了窍门，它实际上是解决问题的非常优雅的方法。

所以基本上，对我来说，这将是决定性因素。如果我的服务器在 Node JS 上运行，我会去同构；否则，我会选择 Catch-all 解决方案，并随着时间的推移和 SEO 要求的需要对其进行扩展（混合解决方案）。

如果您想了解有关 React 的同构（也称为“通用”）渲染的更多信息，有一些关于该主题的很好的教程：

• 使用同构应用应对未来
• 在 ReactJS 中创建同构应用程序的痛苦和乐趣
• 如何实现 Node + React 同构 JavaScript 及其重要性

此外，为了让您入门，我建议您查看一些入门套件。选择与您的技术堆栈选择相匹配的一个（请记住，React 只是 MVC 中的 V，您需要更多的东西来构建完整的应用程序）。首先看看 Facebook 自己发布的那个：

• 创建 React 应用程序

或者从社区中选择其中之一。现在有一个不错的站点，可以尝试为所有这些站点建立索引：

• 选择你完美的 React 入门项目

我从这些开始：

• React 同构入门套件
• React Redux 通用热示例

目前，我正在使用受上述两个入门套件启发的自制版本的通用渲染，但它们现在已经过时了。

祝你的任务好运！

这里的答案都非常有帮助，对我有用的是配置我的 Webpack 服务器以期待路由。

devServer: {
   historyApiFallback: true,
   contentBase: './',
   hot: true
},

historyApiFallback 为我解决了这个问题。现在路由正常工作，我可以刷新页面或直接输入 URL。无需担心节点服务器上的变通方法。这个答案显然只在你使用 webpack 时才有效。

编辑：请在此处查看我的答案以了解为什么需要这样做的更详细原因：https : //stackoverflow.com/a/37622953/5217568

您可以更改.htaccess文件并插入：

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteRule . /index.html [L]
</IfModule>

我正在使用react: "^16.12.0"andreact-router: "^5.1.2" 这种方法是万能的，可能是让您入门的最简单方法。

对于React Router V4用户：

如果您尝试通过其他答案中提到的哈希历史技术解决此问题，请注意

<Router history={hashHistory} >

在 V4 中不起作用，请HashRouter改用：

import { HashRouter } from 'react-router-dom'

<HashRouter>
  <App/>
</HashRouter>

参考：HashRouter

我刚刚使用 create-react-app 制作了一个网站，这里也遇到了同样的问题。我BrowserRouting从react-router-dom包中使用。我在 Nginx 服务器上运行，为我解决的问题是将以下内容添加到/etc/nginx/yourconfig.conf

location / {
  if (!-e $request_filename){
    rewrite ^(.*)$ /index.html break;
  }
}

.htaccess如果您正在运行 Appache，这对应于将以下内容添加到

Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]

这似乎也是 Facebook 自己建议的解决方案，可以在这里找到