前言：做了几年的前端，发现对于后端的知识比较缺乏，而且对于一个项目所要具备，编写的过程没有一个特别清晰的认知，把这些知识做一个串联，把空缺的知识面补上，通过做一个项目整理出来。所以接下来也会通过几个部分编写，然后把自己一些想法记录下来，后面也能够重新回顾，在编码思想上有一个好的进步。不会太注重于代码如何编写，而是总结一些在代码中的思考。
💡 那对于代码的编写，重要的是编写的思路，不是工具的应用，所以在选择哪种语言上选择了node+koa，这样能让我边梳理，更加容易上手，后续用java也是换一个用法，最近公司也是我们一个人负责一个模块的前后端工作，所以也是在同步进行。
🔥 接下来我想整理一个接下来要做的事情，如果没有明确清晰的架构，那也不会清楚自己接下来要干什么。以及每一层要做的事情，一步步来。
技术层级架构
| 结构 | 内容 |
|---|---|
| 展示层 | 包含前端所涉及到的所有内容 |
| BFF层 | 是转发层，也是会拿到做一些接口消费的功能 |
| 数据层 | 就是我们的数据库，我们可以在BFF层消费它 |
技术架构(首先是BFF层)
❓什么是BFF层，先介绍一下。
🤔️ 是一种后端架构模式，翻译过来就是 专门为前端服务的后端层，位于前端与后端之间的适配层。
🐸 当然如果项目只有一个前端，一个后端是不用用到BFF的，当你公司项目多端，显示内容不用，需要更种不同的接口数据，BFF层能够帮到你，增加灵活性，并且多版本维护，接口聚合等等。
性能提升:正常发起请求需要经过浏览器解析域名，dns，防火墙等等一系列节点，通过BFF进行架构调整减少节点。密钥签名，放在bff层不对外暴露。ssr。
缺点： 多了一层系统，运维成本，容易写成 业务后端， 重复开发， 接口膨胀难维护等
编写代码？
在实现代码之前，最重要的是约定好要如何实现。约定优于配置
言简意赅就是，思考文件怎么放，怎么加载，怎么统一命名，这样会对于你后面开发减少很多麻烦。
eg:你实现了十几个不同的功能文件，有controller，service，middleware，那全部放在一个文件里面，哪里使用哪里require？是怎么命名的？
影响: 没有约定好的后果就是，代码不清晰，代码混乱，后续接手的同事需要花费大量时间去理解。
core 出现了！
意思是：核心层，定义框架的运行规则！！
💡：框架怎么运行的？系统怎么启动？请求怎么流动？模块怎么加载？
loader层
💡：自动加载目标文件夹下功能文件，挂载。
思考：有时候写一个功能文件，然后加载，会出现这里一句require(),某个文件又引入同个 require（），所以在写loader 会先定义好controller这些文件要怎么加载，所以在文件结构上会预先定义好。
-
目录结构约定
app/controller/- 存放所有控制器文件app/service/- 存放业务逻辑层代码app/extend/- 存放扩展方法代码，可以向app扩展额外的方法app/middleware/- 存放自定义中间件app/router/- 存放路由定义文件app/router-schema/- 存放路由参数定义文件config/- 存放环境配置文件
-
命名约定
- 控制器文件名自动映射到路由路径
- Service 类名与文件名保持一致
- 中间件函数名即为中间件名称
-
加载约定
- 框架启动时自动扫描约定目录
- 按照预定义顺序加载各个模块
写代码中引发的思考
思考1
情况：
有时候很喜欢写死代码，比如像是定义端口，服务地址，或者一些标识。应该有意识把它们抽离出来。可能会遇到你定义了很多接口，都是/api/bmp/开头。突然有一天，项目搬迁到别的系统，别的系统已经占用了这个标识，要你全部改为 /uav-api/bmp/开头，但是现阶段已经写死在很多文件里，参杂了很多逻辑不说，也不知道改了会影响什么效果。
eg：你有很多个不同模块的api文件，定义的路径都是： /api/xxxx/xxxxx/，然后在vue或者jsx文件中都类似于写死的 http://xxx:8080/api/xxx/xxx/。
这个时候你修改就是全局搜索 /api/xxx/ 替换 /uav-api/xxxx/。一运行：满屏飘红。
思考2:加载顺序问题
可以通过分析依赖关系，优先加载被依赖的模块，避免后续使用的模块没办法调用到。
而在用node+koa中，最重要的是你模块app.use的顺序。不然容易出现拿不到的问题。
思考3:try catch的问题
catch的类型有很多种，文件不存在，代码出错等，在进行日志打印的时候根据报错信息要准确提示相对应错误。
进入了 catch 逻辑，是代码异常，或者编译错误，不一定是文件不存在。
准确使用状态码
eg：301，302，303
💡301:“这个资源永久搬家了，以后请访问新地址”，后端返回location。
浏览器发起请求时候，如果看到301+location，会立刻重新发起一次请求。会发生两次请求。关键是浏览器会永久记忆，浏览器会认为这个资源已经永久迁移，会缓存这个重定向关系。
下次一次再输入地址会直接访问新地址。例如：http->https,后面浏览器记住会直接补成https。
为什么这么设计？减少一次网络请求。
开发配置：
/a
301 → /b
上线后发现：
跳错了
因为用户浏览器已经记住了之前跳转的旧地址。
302:因HTTP协议规定，302状态码要求客户端以GET方式访问新地址，导致原POST数据丢失，早起互联网发现如果post->post会有危险，导致重复提交。现在如果修改，老网站会崩，乱套。
搜索引擎看到：
302
一般认为：
旧 URL 才是正式地址
不会彻底迁移权重
不会永久替换索引
-----
从“提交动作”
变成了
“查看结果”
后续的303，307 被发明，都是为了给前面的擦屁股。303解决用户重刷新问题，有表单提交的时候会弹窗提示是否重复提交。302浏览器可能 GET，也可能不 GET。
持续更新记录中～～后续会重新整理这篇文章，插个眼在这里～～～
