Umi 项目本地运行刷新没问题，但是部署之后刷新页面报404。因为Umi 默认是用 browser 模式，需要做一下处理。
以下是官方给出解决方案。

一、解决方案

1. 方案一：改用hashHistory

.umirc.js

{history: { type: 'hash' },
}

这个方案项目打包只生成一个 index.html 文件
项目路由会带#

2. 方案二：静态化

.umirc.js

{exportStatic: {},
}

项目打包除了生成主 index.html 文件，每个路由都会对应一个 index.html 文件
项目路由不会带#

3. 方案三：服务端配置

修改服务器的配置，以 Nginx 为例：（Nginx配置文件位置为/etc/nginx/nginx.conf）

server {...location /{...try_files $uri $uri/ /index.html; //解决刷新页面变成404问题的代码}   
}

或者

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

这个方案项目打包只生成一个 index.html 文件
项目路由不会带#

另外：
uri 代表请求的文件及其路径，uri/ 表示对应路径的目录。
例如请求 http://example.com/page 时，uri 表示资源目录下是否存在名为page的文件， uri/ 表示名为 page 的目录，这两个参数表示接收到请求时先寻找 uri 对应的文件或目录。
所以，新增的这个配置是为了让浏览器访问不存在的页面时，都给索引到 index.html 。

总结

以上三个方案都可以解决页面刷新404的问题，但是方案一不需要服务端支持，而且处理动态路由比较丝滑，所以如果只是静态页面，推荐用方案一。

二、原理

通常路由分为 hash 路由 和 history 路由。两者具体的实现原理可以看这篇文章。

1. 单页应用

只在第一次加载页面时，返回唯一的html页面和它的公共静态资源，后续的页面跳转都不会从服务端拿html文件。（hash路由和history路由实现浏览器url变化而不刷新页面）

2. hash路由

监听 url 中 hash 的变化， 不需要服务端的支持；

通过hash来实现页面视图的控制，当 # 后面的路径发生变化时，调用 window 的 onhashchange 方法，实现页面刷新浏览器不重新发请求。

3. history路由

监听 url 中 路径的变化，需要客户端和服务端共同的支持；

路由中没有#，当 url 改变时，通过 window.history 中的 pushState() 和 replaceState() 方法，实现更新浏览器 URL 地址而不重新发起请求。

3. 为什么页面刷新会出现404

当刷新浏览器时，浏览器认为是请求一个新的页面，于是真实地向服务器发送了一个 http 的网页请求，而新的页面如果不存在，就会导致404。

如果是页面切换，是不会刷新页面的。比如，当访问 http://example.com/home，会渲染出 Home 组件，点击链接切换到 http://example.com/about，会渲染出 About 组件，同样不会刷新整个页面。

如果是hash模式，当访问 http://example.com/#/home时刷新页面，hash 的值为#/home，仅 hash 符号之前的内容会被包含在请求中，所以发起 http://example.com/的请求，服务器返回 index.html 文件，可以正常显示页面。对服务端来说，即使没有配置location，也不会返回404错误

如果是history模式，当访问 http://example.com/home时刷新页面，会发起 http://example.com/home/的请求，服务器没有这个文件，所以会报404的错误。因此若要使用 history 路由，需要服务端的支持。

另外，为了避免真的出现404页面，前端应该准备一个 404 错误页面。

routes: [{ path: '*', component: NotFoundComponent }]

---

参考链接
Umi FAQ
深入理解前端中的 hash 和 history 路由