大白话讲透前后端，接口，数据库等技术原理!

准备用一篇文章大白话讲透一些大家在工作中遇到的一些技术常识。

比如前端，后端，接口，数据库，页面传参，token。

我们日常生活中肉眼可看到的界面，包括app，网页，小程序，H5等等都属于前端的范畴，可以理解为它们是使用者与后端服务器进行交互的一个工具，通过它来获取和写入数据。

获取数据的过程是怎么样的？

用户点击前端界面的某个按钮后，则前端会触发指令传给到后端，后端接收到前端的指令后，则会从数据库查找数据并加工处理后返回给前端想要的数据，前端拿到数据后，按照指定的样式进行展示。

写入数据的过程是怎么样的？

用户在前端界面输入数据后，则会将数据传给后端，由后端加工处理后将数据写入到数据库的某些表中，最后再将操作结果给到前端，前端对结果进行展示，比如提交成功或失败，给用户一个清晰的指引。

以上只是简要地概括了整个前后端处理数据的流程，让大家快速地对整体流程有个大概的感觉，接下来我再举个具体的例子详细剖析下前后端到底是如何传送，处理及保存数据的

比如数据的写入，我们可以用大家非常熟悉的注册流程来展开讲讲。

首先，注册的第一步，用户需要在注册页面上输入账号和密码，前端会将账号和密码传给后端，这时候，按照上面的说法，后端是不是可以直接把账号和密码写入数据库呢？实际上并不是，上述只是为了方便大家快速理解而简化了处理的过程，实际上后端从前端获取到数据后，还需要做一些逻辑判断:

比如，用户的账号是不是此前已经注册过？如果注册过，这个账号的状态又是怎么样的？是否因为违规被停用过？后端做完一系列的逻辑处理后，也将结果返回给前端，前端接收到结果后，以指定的样式进行展示，这也就是大家在注册的时候，点击登录时所收到的提示。

当然，如果后端判断该账号从来没有存在过，则会将该新账号和密码写入到数据库中，创建出一条新的用户记录。

说到这里，可能就会有人有疑问了，前端好理解，就是一个获取数据的界面，但是后端是什么，跟数据库的关系又是什么呢？

其实，你可以把后端理解为一个数据的加工厂，分别去前端和数据库获取数据进行加工处理，最后给到请求方加工后的结果，后端自己是没有任何数据的，它只有一系列的处理逻辑，所以它必须借助前端获取的或数据库里的数据来辅助它做出合理的判断。

拿上面注册的例子来说，当从前端获取到账号信息后，它还需要跑到数据库中，找到一张专门用于存放用户账号密码信息的表，从这张表中去查找账号的信息，通过两边数据的对比才能得出最终的结论。

为了方便大家加深理解，我再举一个登录的例子，它的处理流程又是怎么样的呢？

首先，用户先打开登录页面，输入用户账号和密码，点击登录后，前端就会将账号和密码传给后端，后端接收到数据后需要做以下的逻辑判断:

该用户账号是否存在？

如果账号存在，密码是不是正确？

如果都正确，让用户成功登录。

如果不正确，则登录不成功。

要判断用户账号是否存在

后端需要拿着前端获取的数据跑到用户表中对比一下看是否存在该账号

如果比对之后发现账号存在，则继续看密码是不是正确。

如果密码也正确，则后端会返回结果给到前端，通知前端这个用户是存在的，前端收到消息后，则让用户成功跳转到首页。

如果后端发现前端传过来的账号或密码跟数据库的根本对不上，则后端同样会将结果返回给到前端，前端收到消息之后，则会触发一条提示，告知用户账号或密码不正确，无法跳转至首页。

所以可见，后端一直都是获取数据，处理数据，最后输出结果的过程，这时候就会引出一个大家在工作中很熟悉的一个名词了，这个名词叫做接口，那到底什么是接口呢？在以上描述的处理过程中，哪些属于接口的内容呢？

大家可以把接口理解成请求方与被请求方互利的一个协议，双方先提前沟通好彼此的需要，我给你什么，你反馈给我什么，确定之后，就按照双方的约定规则落下协议，这就是一个接口，后续我拿着这个协议来找你互换东西，你必须得遵守约定，这就是调用接口的过程。

比如上面注册的例子，前端不需要知道怎么去处理账号信息，只需要把用户账号密码给后端，后端返回给前端具体的注册结果就好了，于是，前端就必须与后端提前约定好，前端应该传给后端什么信息，后端返回给前端什么信息，紧接着，后端就将获取到前端数据后续的一整套处理逻辑，包括与数据库的交互包装成一个接口，定义好接口的地址，后续前端只要按照这个接口的规范进行调用就可以了。

到这里，我们就把前端，后端以及接口基本讲完了，但是，有些人可能又有疑问了，数据库又是什么呢，上面并没有对数据库进行详细说明，大家对它的认知也还停留在它是一个存放数据的地方，当然，还有人可能会说，数据库是研发的事情吧，产品经理或者其他业务岗好像并不需要了解太多吧。

实际上，了解数据库的原理对于做业务的人来说是很有好处的，能够帮助我们更好地跟研发人员沟通，准确地表达自己的诉求，还能对产品的整体架构有更深层次的了解。

比如功能的某个改动点会涉及到底层多大的改动，做好工作量的预估，比如增加某个功能要考虑底层库表的结构是怎么样的，跟研发讨论如何做好延展性等等。

那么，数据库到底是什么呢？

其实说起来也没那么复杂，数据库其实就是一张张的表格，类似excel表，有字段有数值，比如，上面所说的用户账号和密码会存放在一张专门存放用户信息的表中，这张表可能不仅有用户的账号和密码，还会包含用户的姓名，年龄等等，想要获取用户信息都需要到这个表来取。

另外比如电商网站，还会有订单信息，则它们会存放在一张专门用于记录订单信息的表中，比如订单生成时间，订单金额，订单的交易人等等，其他的还有专门存放商品信息的商品表，专门存放卖家信息的卖家表等等。

通常来说，系统中一个实体的信息就会用一张表来存储，比如上面所说的用户就是一个实体，商品是一个实体，订单是一个实体，卖家也是一个实体，于是就会产生很多很多张表。

而且，它们之间并不是互相孤立的，而是互相关联的，比如订单表里面的每笔订单，都需要知道是哪个用户生成的，于是就需要关联到用户表，商品表里面的每个商品，都需要知道是哪个商家上架的，于是商品表就需要与卖家表进行关联，那么，它们是如何进行关联的呢？

每张表的每条记录都会有一个唯一标识，别的表的记录可以通过这个唯一标识与之关联，后续后端到数据库找数据的时候，就可以通过关联关系找到所有想要的数据，比如查订单表的时候，就可以同步查到生成订单的用户是谁，他们的详细信息是什么。

另外，我们还需要了解，表与表存在的几种关系，其中包括，一对一，一对多，多对多的关系，还是拿电商网站来举例。

一个用户可以对应多笔订单，所以用户表与订单表是一对多的关系，则订单表的每条记录都会记录对应的用户id用于关联用户表。

对于电商网站来说，购物车也是一个实体，于是也会有一张专门存放购物车信息的购物车表，而一个用户只能对应一个购物车，所以用户表和购物车表是一对一的关系，所以可以在用户表记录一个购物车id进行关联，也可以在购物车表记录一个用户id进行关联，后续查询购物车记录的时候就可以知道是哪个用户创建的。

一个卖家可以卖多个商品，一个商品可以被多个卖家卖，所以卖家表与商品表是多对多的关系，对于多对多关系，记录方式就不能跟一对一，一对多关系一样了，总不能在一条记录的后面记录一堆的关联id吧，所以，有一种更好的记录方法，就是做一张中间表，专门用于存放它们之间的关系，每一条记录就是一个关系，这样的记录方式更加友好。

所以，到这里数据库的原理就基本讲完了，总而言之，数据库只负责存储数据，而后端则按照前端的请求，到数据库关联的各个表去取数据进行逻辑处理，返回处理结果给到前端进行展示，只要能这个流程理解清楚，以后跟研发同学沟通基本就不会有太大的障碍。

最后，我再给大家普及一个在工作中经常会听到的一个术语，叫做页面传参，很多人并不是很理解，他们只理解接口传参，知道请求后端的时候要将参数传给后端处理，但是，页面传参又是什么东西？

这种传参方式一般只会存在于页面跳转的场景，一个页面跳转到另外一个页面时，把第一个页面获取到的参数按照一定的格式拼接在第二个页面的链接上，第二个页面加载后即可获取到该参数。

比如，用户在登录页面登录后，也会将用户信息通过链接传给首页，首页则会调用后端接口，通过用户信息获取到对应的数据。

另外，还有一个常见的名词叫做Token，比如有时候我们去问研发为什么app老是要我们登录，他们会跟我说，token失效了，那token是什么呢？我们可以把它理解成后端给到前端一个入门的凭证，类似门禁卡一样的东西，你拿着你的身份证信息去物业记录了你的身份，物业对应给你一个门禁，后面你进小区就不需要老是拿着身份证证明你自己了，只要有门禁就可以进小区，token也是一样的东西，前端拿着用户的信息去后端换回了一个规定了有效期的token在前端缓存着，只要它不失效，就不需要再拿用户信息去请求后端，直接就可以登录。