后端开发从入门到精通：完整教程指南

首先我们来看一下前端页面的渲染（Vue + Vux + Vuex + Vue-Router）。

php

* 第一次做gif，没经验，太大了，加载慢 * 前端

项目地址：，您可以在手机上打开查看效果。

好了不说废话了，说说后端git

关于后端我应该写些什么？我应该写些什么才能对我更好的总结，才能更好地帮助到大家？在准备写的时候，我想了很久。

我准备了一个手把手教的教程，我觉得没什么意思，如果是step by step的教程，还是看视频比较好，想着可能对大家更有帮助，总结一下后端结构（注意是结构，不是架构）设计，代码组织，模块划分等。github

后端开发疑虑

后端开发最常面临的问题就是性能，高并发等，不过这不在本文的讨论范围之内，我们只会讲如何写好代码，如何划分业务模块。

大部分高性能、高并发的解决方案都是代码之外的扩展。

那么从纯编码的角度来说，如何写出好的后端代码呢？我经常会有这样的问题：什么代码应该放在 Controller 层？Model 能做什么？它自身的一些扩展和工具类应该如何组织？

发现现在疑惑少了，如果还有疑问可以留言，我们一起学习讨论后端。

虽然代码主要用来实现业务逻辑，但是选择一个好的框架对于提高团队的敬业精神、让代码层面的性能无忧还是很有帮助的。

框架的选择

说实话，自从PHP7发布以来，代码级别的性能已经达到了很高的水准，基本上百万级别左右的系统，已经不用担心语言层面的问题了。

框架方面，我用过的PHP框架有（前后）：ThinkPHP Laravel 不知名的自制框架 Yii Phalcon

本文整个代码结构设计和组织设计都是基于Phalcon的，除了自研框架之外，其他框架都是非常优秀的框架，只是框架本身的性能在逐渐提升，不过经过一些整合之后，其本身的性能也能逐渐提升，比如Laravel Yii和Swoole的结合也能达到Phalcon的水平。

PHP的版本为：7.1（如果你是新项目，必须使用PHP7）

后端该做什么

当然，你必须先设计db，不过这不在我们讨论的范围内，我们先假设这一步已经完成了。

我们的代码需要提供以下能力：命令行脚本、API 版本、后台管理。当然这三部分也可以拆分成三个项目，但是对于小公司、小项目来说没必要（放在一个项目中增强了代码的复用性）

这三个都是比较大的模块，接下来我们来逐一分析一下。

命令行脚本

先说一下命令行脚本，它是一个相对独立的部分，不需要用户调用，主要用来完成一些定时任务，现代框架都提供了这个模块。

Phalcon提供了CLI模块可以很方便的完成这部分功能，其代码依然以MVC结构编写，但是访问是通过命令行进行的。

就像一个简单的 CLI

class MainTask extends Task {    public function mainAction() {        return fwrite(\STDOUT, 'hello task!')    }}

API 模块

刚接触 API 这个概念的时候，我很迷茫，觉得很高端。现在我理解它是一种前后端之间纯数据通信的方式。以前我们做 Web 开发的时候，是不提供 API 的，而是直接在后端把数据渲染到页面上。用户直接在渲染出来的界面上操作，然后通过按钮或者其他什么方式触发对后端的请求。

API 时代，Web 出现了前后端分离的概念，而移动端的后端更是没有渲染能力（自然也就前后端分离了）。因此后端需要将数据发送给前端，前端根据数据的描述，将数据以用户能理解的方式展示出来。比如一个产品的 API 结构可能是这样的：

{    code: 1,    msg: 'query ok',    data: {        name: '最凉快的空调',        price: '9999.00',        img: 'xxx.webp',        stock: '10'    }}

这种方式可以让前后端的开发相互独立，你可以专注于自己的工作。但这也带来了另一个问题：前端有所谓的版本，后端必须考虑到所有使用的版本。如果我们永远只使用一个 API 地址，那么代码可能会相当丑陋。

比如现在有一个新的需求，之前空调只有一张图，现在空调展示的时候是有多张图，那么就有两种方式，一种是增加一个字段，一种是将原来的字段img转为数组。

如果增加字段的话，不会有兼容性问题。但是如果将 img 类型改为数组的话，之前的版本就无法解析这个类型了，所以如果要改成数组的话，只能整体升级 API 了（一般不会因为这个问题而升级）。

那么有哪些方法可以对 API 进行版本控制呢？我使用 Phalcon 的模块对 API 进行版本控制。我之前也尝试过控制器版本。例如：

ApiV1Controller 表示这是 v1 版本。ApiV2Controller 表示这是 v2 版本。Phalcon 的模块为版本提供了极大的便利，只需新建一个模块，命名为 v1 即可。如果以后要升级，则新建一个模块，命名为 v2。对于不需要修改的功能，可以简单的让 v2 ​​的控制器继承 v1 中的控制器即可。

至于API的版本，我们可以简单地通过URL来获取，例如：

版本信息一目了然。

后台管理

大部分系统都需要一个cms来上传和修改相关数据，以Accelerator为例，你需要上传游戏，编辑一些游戏合集等，你可以把它做成一个单独的项目，也可以依然使用模块的方式进行开发（我比较推荐，这样可以很大程度上提供代码的复用）。

最让我不能接受的一句话是：后台做就好，反正也是公司内部用的。

作为一个有志于成为程序员的人，一定要有底线，我们的目标是让你的工作更方便，更轻松，最后让你无事可做（哈哈哈）。因此，在后台我也比较推荐前后端分离，通过 Vue 进行开发。

目前的后端是使用 Vue + Element UI + Vuex + Vue-Roter 开发的，网上参考了下面这篇文章：手把手教你用 Vue 搭建后端，写的确实很好，让我学习的时候少走了不少弯路，尤其是前端权限控制部分，他的方法让我感觉耳目一新，刚刚搭建了我的后端基础部分（路线规划，一些扩展的 Vue 插件）

前后端分离之后，后端其实可以归为API开发的部分。而这样做的一个好处就是，如果以后后端需要做移动版的某些功能，API已经准备好了。

待续

写代码的时间越长，对语言层面的理解就会越深刻，只要你多做，很快就能达到一定的境界。但是，无论你写了多少业务代码，都不能让你在技术领域走得更远。所以如果你有幸在一家大公司工作，有机会接触到大项目（几百万、几千万用户），一定要仔细观察，这个项目那么多人是怎么开发的，它怎么还能运转良好？它是怎么把业务逻辑和系统架构解耦的？如果你在一家小公司，那么就尝试自己搭建一些系统，这样就可以在这个基础上开发业务，而不用担心一些底层的东西。新手写业务也能很快上手。

后端部分可能还会有两到四篇文章，主要包括后端项目结构的划分（我曾经在三四个项目中尝试过使用这种结构，效果很好）、后端登录控件（会开源一份Phalcon oauth2的代码）、后端API的自动化测试等。

相关代码我会一一放到github上，姑且把所有代码都叫做x-吧，x从小学数学开始就给我留下了很深的印象。

- x-api 是一个 PHP 后端项目

- x-control 是一个用vue编写的后端管理系统

- x-client是vue系统的客户端接口