为什么写这个专栏？ 有些小白“自学”过程中百分之一千会有这样的疑惑： 我学完了 Python / Java，但仍然做不出一个网站（项目）。 而且关于学习这个问题（尤其是自学），某乎上面的回答都很全，但还不够实用。因为缺乏具体场景做出的回答实用性不强。
我只讲答案。（我也是这么过来的，我知道 你的 不知道） 你应该先学习 全局 / 全流程 做事的 套路，然后在去做事。 这里面的逻辑就是 学习 做事 再去 做事。 然后，基于这套做事的逻辑，你是要做一个网站，还是一个APP，做事的目标要明确。 剩下的问题就是 找学习资源 ---> 使用资源 ---> 完成目标。
(目录)
0. 开门见山
通过本专栏，你不仅可以学到完整的电商逻辑开发，还可以学到企业项目通用的解决方案。 从两个大方向来划分，框架核心、框架基础服务，框架核心我们可以学到容器，依赖注入，门面模式，中间件，服务，事件路由，驱动，这些基本上都是框架的核心和灵魂。 从框架基础服务当中我们可以学到控制器的巧用，模型，视图，请求，响应，异常处理，日志，错误，调试，验证，多应用，缓存等等，这些内容都会在我们的专栏项目当中一一涵盖。
还会分享一套代码分层架构，能够做到高度解耦多复用的能力。 其中包括5层架构， 控制器层，controller 业务逻辑层，business 内部基础库层，lib 视图层，view 模型层，model。 每一层都有它相应的职责。比如说控制器层它只负责接收请求的参数，然后对参数进行相应的校验，然后去调用业务逻辑层的内容，业务逻辑层它只负责去获取模型层返回的数据，然后对模型层的数据进行相应的组装，它还会去请求内部基础库层的数据，同样也会进行相应的封装，然后把数据呈现给控制器层，模型层它只负责去调取数据库里面的数据，它的职责很明确，只负责去调数据库里面的数据就可以了，它并不对数据库里面的数据拿到之后再次的进行封装，它的职责不会这样去做。 而lib层是一些基础库的封装，视图层它只负责一些相应的模板引擎，比如说我们的后端页面是采用了 layui 前端框架，那么这个时候我们就可以结合 模板引擎 来处理视图层的逻辑，这样的话控制器层会去调用视图层的内容，然后视图层将内容返回给控制器层，最终呈现给我们的用户，是这样的一种思想。
接下来我们再来看一下我们项目当中电商核心的技术点，其中包括反作弊场景，关于反作弊它是电商系统不可缺少的一个环节，因为我们可以利用它来解决黑产进行抛羊毛的场景，所以说它是我们系统当中一个重要环节。 消息队列，关于消息队列，我们会从最基础的什么是消息队列？为什么要使用消息队列？消息队列的使用场景，以及我们使用消息队列之后，我们能带来什么收益？并且我们还会利用 redis 来做最简单的消息队列，最后过渡到 kafka，循序渐进的方式来讲解这个消息队列。 redis 集群 ，负载均衡，限流，在限流当中，我们会采用 nginx+lua+redis 来做我们的限流场景，服务容灾，系统降级，性能优化，商品抢购，并发锁，分布式session，服务评估。
在服务评估当中，我们会根据不同的 qps 来评估我们系统的架构，比如说当我们 qps 达到5000的时候，达到1万的时候，达到2万的时候，达到5万的时候等等，我们如何去架构我们的系统服务，这是我们的关键。 压力测试，排队机制。 优秀的开发者能力往往会体现在调试过程中问题挖掘，如何快速定位系统问题是一个非常重要的环节，本专栏也会带领大家手把手的教你如何去挖掘系统存在的一些问题。
支付的服务化，支付会采用阿里支付，微信支付，并且我们还会把它单独抽离出来，做成一个微服务的思想，从而做到高度解耦。
以上是我们电商核心的技术点，这些内容都会在我们的后面的实战内容中一一的进行讲解，在我们课程当中会讲解企业级开发流程，让大家对企业级开发流程有一个初步的认知，并且后面的实战也是严格按照这种流程进行相应的开发。
我们的开发流程会包括需求评审，需求评审它会涉及到很多人员，包括产品经理、开发工程师、开发工程师会包括前端工程师、后端工程师、测试工程师、UE设计师等等这些人员，大家坐在一起进行需求的评审，看一下哪些需求合理，哪一些需求不合理，不合理的我们剔除掉。
还有一种场景就是没有考虑到的需求，我们也可以在需求评审完这个地方加进去。我们的需求评审完之后，这个时候的话并不是一次就过了，可能会涉及到两次三次等等以上，最终会定一个需求评审的最终版本。
然后接下来设计师就会根据最终的需求进行相应的设计，设计相应的图，比如说我们的电商项目，设计师的话就会去布局我们的电商的图，有哪些功能，如何进行相应的交互等等，这都是设计师需要做的。
UE设计师把这个图设计好之后，接下来还需要进行评审，看一下这个图是否满足我们的需求，这个时候同样需要包括 UE 设计师、开发工程师、产品经理、测试工程师等等，我们坐在一起进行 UE 图的评审，最终我们会定一个初版，然后慢慢的进行一个最终版本的确定。
UE图确定好之后，接下来的话我们前端工程师和后端工程师就需要去定我们的接口了。因为我们的项目当中会涉及到很多 API 接口，这个时候我们需要双方工程师进行相应的协商，看一下某一个功能需要什么接口，访问什么字段，这是两类工程师一起才能确定下来。比如说你后端工程师，一个人定的接口没有任何意义，因为你定的接口不一定适合前端工程师，知道吗？所以这是很关键的因素，需要大家一起决定。
定完之后，双方工程师就可以进行开发了，比如说后端工程师直接去开发它的接口，前端工程师就去布局它的页面，后端工程师如果开发完了，他首先需要进行自测，我在我本地测试没问题，这个时候我就发起联调，我把我的接口给前端，然后我们一起进行相应的联调，联调完之后，同样前端工程师和后端工程师要整体的对当前功能进行一个相应的测试，测试完之后，开发工程师觉得没有问题了，这个时候方可进行提测，提测给谁 就提测给 QA 工程师，或者说叫测试工程师，而测试工程师就会对我们整个的功能或者项目进行第一轮测试，测试肯定会遇到一些小小的问题，这个时候测试工程师就会发一些测试报告，说你这个地方有什么问题需要修改，这个时候像后端工程师都要针对于测试工程师提的这些建议，bug 进行相应的修复，修复完之后再进行相应的提测，最终 QA 工程师认为没有问题了，才能够方可上线。
这个时候 QA 工程师必须要去发一个测试报告，认为本次功能没有问题，可以上线，这个时候我们的前后端工程师才能够进行相应的上线，那么这是我们整个开发的流程。
接下来我们来看一下我们的页面展示， 体验地址：http://39.107.30.137:8089/ 这个地方我们只展示项目当中的前端页面，我们的前端页面是采用 VUE 进行相应的构建，ta直接会去请求我们的后端 API 服务，这是我们的首页，我们的首页会包括分类、搜索、购物车、轮播图，商品某个分类的推荐，这是我们的商品详情页，点击某一个商品会进入到商品详情页，我们会展示单个商品的详细信息，并且还会支持 sku ，立即购买，加入购物车，爆款推荐，
这是我们的登录页面，我们的登录页面会采用手机号加短信验证码的方式进行登录，短信验证码我们是使用阿里云短信的方式，这是我们的订单列表页，这是我们的个人中心页面，个人中心页面我们会有个人资料，收货地址等等这些内容，
这个是我们的支付页面。 关于支付页面，我们会使用支付宝和微信支付的方式，并且在课程当中我们会把支付宝，微信支付这些支付的场景会单独抽离出来，做成一个服务化，从而做到高度解耦。 因为这样的话，后续比如说我们的电商可以使用，活动也可以去使用支付，很方便。
接下来我们再来看一下我们 项目的功能点。 从两个大方向来划分的话，包括电商前端和电商后端， 前端我们会包括首页、商品详情页、注册登录页、购物车页、订单页面、支付页面、商品列表页面、个人中心， 后端我们会包括登录、商品管理、分类管理、订单管理等等。
首页会包括商品展示，搜索分类，支持无限极分类，购物车，页面静态化，redis 缓存， 商品详情页会包括sku设计，购买，加入购物车，爆款推荐，高并发下商品的抢购。 登录页面会包括手机号加验证码的方式进行登录。分布式session解决方案， 支付页面我们会包括微信支付，支付宝支付，在前期过程当中，我们的微信支付、支付宝支付会在我们电商系统当中开一个小小模块，后续为了高度解耦，我们把微信支付和支付宝支付单独抽离成一个服务，进行高度解耦。
个人中心包括个人资料、收货地址，我的订单等等。 后端当中，我们的商品管理其实还会包括很多的功能，比如说 sku 的设计和管理，图片上传，多图上传，分页搜索等等， 分类管理，我们支持无限极分类等等， 这些都是我们需要或者说常见的一些功能点。
1. 开发流程和规范
本小节我们来学习和了解 开发流程和规范的说明。 那么一般来说，开发流程基本上都是会按照如下的方式去进行， 首先会有一个需求，那么这个需求是来自哪里？基本上是我们的产品经理确认，确认好需求之后，我们会进行一些需求评审，需求评审的时候会有哪一些人员参与？ 比如说有产品经理，然后有开发工程师，那么开发工程师它会分很多类，比如说有后端的前端的，前端又包括比如说FE以及AP端的，比如说iOS开发工程师，安卓开发工程师等等这些，可能还会涉及到你们的负责人对吧？ 你们的经理我们都可能会在一起，比如说在一个小会议室，我们一起来讨论一下这个需求是否合理，哪一些需求我们需要砍掉，哪一些需求，我们比较着急，在本次开发中我们需要去完成，那么这个是需求评审要做的事情。
评审完之后，我们确定最终这一版我们需要开发的内容，这个时候的话我们的设计师就会根据我们的需求去设计相应的图，那么这个时候就是第二点，UE图设计，那么 TA 会根据我们之前评审的最终的需求去设计相应的图，设计完之后，这个时候我们还会去进行一些评审，评审最终的设计师设计的图是否和产品经理最终定的需求是否一致，这个也是需要去评审的，不然的话 UE 设计完这个图之后，并不是产品经理最终想要的这种情况，这样的话也是没用的，所以这个中间也会有一个 UE 图的评审过程，设计图完之后，我们就可以接下来对我们最终的内容或者说需求进行一些接口的定义。
比如说我们当前这个需求有10个功能，这 10 个功能可能会涉及10~15个API，这个时候我们后端工程师和前端工程师需要协商，我先定一套接口，把接口先定义好，定义好之后我们才能够进行接下来的开发。因为你接口没有定义好，你就去开发，这个时候其实是会有一些问题的，并且这个接口定义是需要前端工程师和后端工程师一起讨论，最终定一个相应的接口文档。
因为不然你后端工程师自己下定义并不适合于前端工程师的规范，这也是不合理的，所以必须两类工程师坐在一起讨论，最终定一个约定书成的接口文档。【swagger，yapi，showdoc，自己写的markdown，语雀，石墨】
那么这个接口文档它其实是有一个最基本的规范，比如说有一个状态码，有一个消息提示，还有一些数据字段，这个时候可以有status代表状态码，message代表消息提示，然后有个list或者说data代表第三个字段的数据，这个后续我们会做详细的介绍。
这里的话大家只需要了解一下就可以，这个文档定好之后，这个时候的话我们前后端工程师就可以去开发内容了，后端工程师就根据某些功能，然后开发不同的接口进行相应的开发，前端工程师就会根据 UE 设计的图，然后进行相应的布局等等这些内容，然后我们后端工程师把接口开发完之后，就可以把接口提供给前端工程师。
怎么提供？一般来说，后端工程师会把相应的功能或者说API服务会部署到比如说测试环境，看你们的情况而定，一般我们是会部署到测试环境，后端工程师开发的时候会在自己的本地进行相应的开发，开发完之后，如果要和前端进行联调这个事的话，需要部署一个测试环境或者说联调环境，不然的话多人开发的时候可能就会冲突，对吧？
所以一般是这样的，那么这个时候就涉及到前后端联调，前后端联调我们需要部署一个独立的环境，专门是进行相应的联调的，因为这样的话，我后端工程师我开发的时候就不会影响前端工程师联调的进度，不然如果我们后端工程师，比如说我自己要修改一个内容，这个时候服务器崩掉或者挂掉，前端工程师他去联调的时候接口访问不了，其实是会影响他的进度的，所以说我们联调环境一定要去独立单独开一个环境出来，直接放联调环境上面，那么前端工程师就很好的进行相应的联调就可以了。
联调完之后，这个时候我们需要关注是什么？首先我们需要的是前后端工程师自己去整体的测试一下这个流程，你得确保我们自己开发的功能没有bug，虽然不能百分之百的把握，但是我们必须要自行的去测试，在自己的范围之内保证没有任何问题。
这就是自测，自测完之后，我们就需要提测，提测给公司级的 QA，也就是测试工程师。一般的公司都会有测试工程师专门进行功能测试，他会根据产品经理定的需求，然后他会去写一些测试用例，然后最终我们提供给他一个测试环境，他就会进行相应的测试，相对来说他的测试场景会比我们前后端工程师自测的场景要专一一点。
他测试完之后，这个时候，他就会针对于有一些不合理的场景，或者说有一些隐藏的bug，他会提出来，提出完之后，我们前后端工程师就根据自身的情况去进行相应的修复，修复完之后继续提测，那么直到我们的功能没有任何问题了，这个时候方可上线。
在上线之前必须要经过我们的 QA 工程师进行确认，比如说他认为当前的功能没有任何问题了，他会发一个测试报告，当前有多少bug，修复了多少bug，然后最终我们的功能没有任何问题，达到上线的标准，类似于这么一个测试报告抄送给我们的后端前端工程师以及经理，这个时候我们才能够去上线。
上线完之后，这个时候还需要前后端工程师以及 QA 进行相应的测试，看一下线上是不是有问题。
那么关于这个上线一般中大型公司它都会分级发布，比如说先小流量上一台机器，然后观看一下机器是否有问题，然后在小流量的比如说10台或者20台先上一下，最后进行全量，一般的流量是这样的，它会有一个分级发布，先上一台，再上10~20台，再上最后的全量，那么中间你还上多少无所谓，大致的流程是这样的，他会先分级发布，先上线一点，再上一点，最终全量，是这么一个逻辑。
开发流程基本上中大型公司都是按照这种场景来做的。 那么我们还需要去严格遵守我们的规范说明。 我们的开发当中必须要有接口文档，这个文档是非常有必要的。为什么这么说？因为它能够解决很多问题，首先我们可以通过前后端一起约定一个文档，这样的话就能够减少很多不必要的麻烦，对吧？因为比如说你后台工程师如果随便写一个接口，根本不适合前端，这个时候是做了很多无用功的，所以他能够节省很多时间，并且也很规范，
还有一点非常有用，也就是说如果你们当前项目组有新加入的同学，这个时候如果我有接口文档也很规范，这个时候的话他上手的话也是非常快速的，有这个文档之后，我们还需要有联调环境，因为我们说了联调环境主要是给前后端进行相应联调的时候用的，然后需要有测试环境，测试环境主要是我们把前后端的代码放到测试环境，最终提供给 QA 工程师进行测试的，这些环境最好都是独立，最后 QA 测试工程师测试的我们工程之后，他需要有一个测试报告，这就能够说明我们当前的一种权威性，然后就方可上线。
那么以上这些我们开发流程和规范的说明。
2. 学习学习再学习
先讲套路， 多看， 多练， 多总结。（尤其是博客，markdown笔记）
多看 究竟 看什么？ 首先需要多看看网上的学习教程（B站，慕课网，YouTube，公众号，博客），或者一些大牛出的书籍（没有名气的作者出的书别买，这是坑） 看看别人是如何去实现这个功能的，这样的话能够给你带来很多收益，并且少走很多弯路。
我们需要去多看一些文档，这个文档包括比如说你对 Go语言 Gin框架中 提取网页的标签信息（类似于 Python 中的 BeautifulSoup 实现的功能）不了解，我认为你需要去多看一些 Gin 的官方文档，看一下它怎么去实现，怎么去较好的应用到某些场景。 这都是技术群里的小伙伴具体遇到的问题。
多看它的文档，然后去一一实现里面的一些场景，我认为这样坚持下去，你对Gin 使用的场景或者说它的知识点肯定是掌握非常不错的。
我们还需要去多看一些技术文章，可以通过 51CTO ， CSDN，博客园，掘金等等这些官方网站去了解一些最新的技术。
我们还需要去多阅读一些优秀的源码，比如说你可以通过 GitHub 上去找一些关于 Go 的开源项目的源码，通过阅读它们的源码，我们可以发现自己身上的不足，我认为阅读源码是能够快速提升我们技术水平的一种手段。
第二大块我们需要去多思考多实战，怎么去理解呢？ 比如说公众号中有些大佬写的内容，我们一定要去反问几个为什么这样做，为什么不能这样做？ 如果我这样做会达到一种什么效果，并且我们还需要举一反三，他讲的场景，我能不能把他的这种思路运用到其他场景，并且我们还需要进行相应的扩展，比如说他的文章当中某一些功能点没有去讲，我需要自行的通过他之前文章讲解的内容/思想/提示，我把这种场景运用过去，自行去完善扩展其他功能，
我们还需要去多实战，你光看人家写的东西，其实是没用的，一定要去边看边想，然后再去敲代码，这样的话才能够有更好的收益。【输入 输出 相结合】
第三大块我们需要去多讨论，在哪里讨论，我们可以在 QQ 群 / 微信群里面和伙伴一起讨论学习相关的一些内容，多讨论也是能够提升我们技术水平的一种方式。
第四大块，我们需要有分析问题的能力，有很多小伙伴在遇到一个问题的时候，比如说它运行一个项目直接报错，他就无从下手，那么这种场景对于初学者来说可以理解，如果你遇到一两次不能解决没关系，首先我认为你要平静下来，不要浮躁，你可以先看看它的日志，它报错的日志定位到什么地方，对吧？ 日志里面一般都会体现它在哪一行哪个文件报什么错，你先去看日志，然后看能不能解决。 【那些忙于毕设 / 答辩 的同学尤其需要关注这点】
如果不解决，首先我认为你先去百度/谷歌找找有没有相应的人遇到类似的问题，有没有相应解决方案？你并不是遇到问题就很浮躁，而是需要我们提升我们的分析问题的能力【这是一个什么样的问题我知道吗？】，这个是很关键的，在实际工作当中我们这一点也是我们的核心竞争力。
第五大块我们是需要学会如何高效的提问。
那么关于提问我建议几点，第一我们的提问的话，我希望大家是经过思考之后再提问，并不是一遇到问题就在群里面抛个问题，然后再问 再抛个问题，这是没有任何意义的。
我们要先思考，思考完之后如果你再解决不了，我们才能够去评论区/群里/邮箱面提问，并且提问一定要把这个问题描述清楚。
因为我遇到很多伙伴在提问的时候，有些问题我根本看不懂，他没有描述清楚，我不知道他在讲什么，所以为了提升效率，我建议大家先思考再提问，并且把问题描述清楚，这样的话别人能够较好的帮助你解决当前的这些问题。
提问模板：
