工程目录结构
我们创建UmiJS后默认会创建一个简单的工程模板，此外UmiJS文档中也描述了一个推荐的工程目录最佳实践。UmiJS对于工程的目录结构有一些约定，我们应该按照规范的目录结构进行开发。
UmiJS工程目录结构详解
UmiJS官网给出的工程目录结构如下。
├── config
│ └── config.ts
├── public
├── dist
├── mock
│ └── app.ts｜tsx
├── src
│ ├── .umi
│ ├── .umi-production
│ ├── layouts
│ │ ├── BasicLayout.tsx
│ │ ├── index.less
│ ├── models
│ │ ├── global.ts
│ │ └── index.ts
│ ├── pages
│ │ ├── index.less
│ │ └── index.tsx
│ ├── utils
│ │ └── index.ts
│ ├── services
│ │ └── api.ts
│ ├── app.(ts|tsx)
│ ├── global.ts
│ ├── global.(css|less|sass|scss)
│ ├── overrides.(css|less|sass|scss)
│ ├── favicon.(ico|gif|png|jpg|jpeg|svg|avif|webp)
│ └── loading.(tsx|jsx)
├── node_modules
│ └── .cache
│ ├── bundler-webpack
│ ├── mfsu
│ └── mfsu-deps
├── plugin.ts
├── .umirc.ts
├── package.json
├── tsconfig.json
└── typings.d.ts
config/config.ts和.umirc.ts
该文件是UmiJS工程的配置文件，config/config.ts和.umirc.ts用途是相同的，我们实际开发中选择一种配置方式即可（一般都使用config/config.ts），两种同时用会有烦人的优先级问题，不仅是前端开发任何工程都不应该把配置文件布置的过于分散。
避坑：这里尤其要注意，Umi4零配置也是可以正常启动调试、构建的，如果没有找到配置文件也不会有任何错误或是警告信息输出，如果你发现怎么改配置都不生效，可以考虑是不是配置文件是不是放错目录了（比如错放到了src下），或者写错文件名了。
public
public中可以放置静态资源文件，例如图片、音视频等。
dist
dist是工程编译的输出目录，我们实际部署工程到服务器时，部署dist中的内容就行了。
mock
mock目录中可以放置一些模拟接口，用于前后端分离开发时，后端接口还没开发完前端自己进行模拟的情况。
src/.umi和src/.umi-production
这两个是UmiJS框架的临时文件，分别会在本地调试（dev）和构建（build）时生成，其中包含的自动生成的代码会和我们的业务代码最终编译到一起。注意不要将.umi和.umi-production提交到代码仓库，也不要修改其中的任何内容，这两个目录是由框架维护的，我们手动修改可能引发意想不到的错误。
此外，如果实际开发中.umi目录缺失造成IDE报错等情况，我们可以执行npm run setup重新生成临时目录。这里npm run setup实际执行的是umi setup。
src/layouts
src/layouts包含了布局代码，布局可以和路由结合使用，用于显示类似管理后台的框架这类UI组件。
src/models
src/models是数据流插件放置数据模型代码的路径，如果不使用数据流插件，可以不创建。
src/pages
src/pages存放具体的页面代码。Umi4支持类似NextJS的基于文件路径的约定式路由，但实际上我个人还是认为应该使用在配置文件中声明路由的形式。
app.ts
app.ts是运行时的扩展配置文件，用于对路由、请求等组件进行运行时配置，比如request插件的拦截器就需要在这里进行配置，其中的代码是在浏览器端执行的。
global.ts和global.css
这两个文件包含全局运行时逻辑和样式，其中样式也支持Less等。
overrides.css
overrides.css专门用于对UI库中的样式进行覆盖，相比global.css它会添加body前缀抬高优先级。
favicon.ico
该文件是站点的favicon图标。
plugin.ts
在这个文件中，可以使用UmiJS的插件API创建项目级的插件逻辑。
package.json
npm工程描述文件。