-
须要理解的目录及文件：
建设第一个 umi 我的项目并启动后，可能会有一个疑难：这个我的项目的启动文件在哪呢？一般来说，咱们通过 react 的脚手架建设的我的项目中，在 src 文件夹的根目录会有一个 index.js 文件，在 index.js 里咱们通过 ReactDOM 的 render 命令来启动我的项目。然而在 umi 的我的项目中，src 根目录下并没有 index.js 文件，也找不到 render 这样的指令代码。
查看 package.json 文件里的 start 命令，咱们晓得我的项目的是通过 umi 指令启动的，而 umi 启动的入口文件，其实就是 src/.umi/umi.ts。
从官网的文档咱们能够理解到，.umi 是一个长期文件夹，.umi 长期目录是整个 Umi 我的项目的发动机，入口文件、路由等等都在这里，这些是由 umi 外部插件及三方插件生成的。
同时， 临时文件是 Umi 框架中十分重要的一部分，框架或插件会依据你的代码生成临时文件，这些原来须要放在我的项目里的脏乱差的局部都被藏在了这里。因为他的临时性，每次启动 umi 时都会被删除并从新生成。
而我的项目的根底配置则是放在我的项目根目录的.umirc.ts 文件中。如果须要多平台简单配置，则不必.umirc.ts 文件，在根目录下建设 config 文件夹，在文件夹下建设多个文件进行配置。例如以下示例：
当咱们扭转配置时，重新启动我的项目，src/.umi 目录下的内容就会依据咱们的配置从新生成，也就是说，这个入口文件夹里的内容是在咱们编码过程中，依据咱们的配置和插件内容的变动而动态变化生成的。
另外咱们还能够在 src 的根目录建设 global.tsx，global.less 这里两个文件，这两个文件默认会在我的项目启动前被引入，global.less 能够搁置一些全局的款式，global.tsx 能够解决一些全局性的异步事件等。
-
约定化的思维：
(以下内容转自：http://www.zyiz.net/tech/deta…
umi 的很多货色都是约定式的。所谓约定式就是指，依照约定好的形式开发，就能达到某种成果，两头的过程由框架帮咱们实现。例如：
- 建一个 locales 目录，就领有了国际化
- 建一个 models 目录，就领有了数据流
- 建一个 mock 目录，就领有了数据 mock
- 建一个 access.ts 文件，就领有了权限策略
- …
这看起来是十分黑盒十分酷的，用这种形式其实对于团队代码格调的对立是十分有益处的，间接在框架层面就束缚了大家的目录组织模式，便于团队保护。
然而毛病也是挺显著的，灵活性不如配置式的高，因为只能按特定的模式来开发，如果本来约定的形式不满足业务需要，就须要额定开发 umi 插件来魔改本来的性能。而且约定式的开发是绝对其余框架来说很特地的一点，对新上手的同学来说须要工夫去通读官网文档理解约定式的规定。