写在前面

本文主要是针对 laravel 框架来说明的，不过核心思想都是差不多的

先放几个链接：注意切换版本

• laravel 中文文档

• laravel 速查表

• 深入 Laravel 核心

• PHP PSR 标准规范

PHP PSR 标准规范

只能说尽量向规范靠拢 PHP PSR 标准规范参考文档

以下是我节选出来的部分，完整请看上文参考链接

1. 概述

• 类的命名 必须 遵循 StudlyCaps 大写开头的驼峰命名规范；

• 类中的常量字母都 必须 大写，单词间用下划线分隔；

• 方法名称 必须 符合 camelCase 式的小写开头驼峰命名规范。

3. 命名空间和类名

• 命名空间 和 类名 必须 遵循 【自动加载】 规范

4. 类的常量、属性和方法

此处的「类」指代所有的类、接口以及可复用代码块（traits）

• 类的 常量 所有字母必须 大写，单词间以 下划线 分隔，例如：

<?php
namespace Vendor\Model;

class Foo
{
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';
}

• 类 的属性可以有以下几种

1. 大写开头的驼峰式 ( $StudlyCaps)
2. 小写开头的驼峰式 ( $camelCase)
3. 下划线分隔式 ( $under_score)

• 类 的 方法 名称 必须 符合 camelCase() 式的小写开头驼峰命名规范。

Git 操作

所有新分支，从 master 拉取，然后提交合并到 dev，测试无误之后，再将合并请求提交到 master

如下图所示：

开发环境

本地PHP开发环境建议用phpstudy小皮系统，官网地址

• IDE编辑器：PHPStorm，版本随意，配置强烈建议统一（代码风格，缩进，对齐等等）， 激活方法

• Git：官方下载地址

• MySQL：5.7+（集成环境切换版本）

• laravel：LTS版（5.5、6.0）

• Redis桌面管理工具：redis-desktop-manager，点击下载，提取码：yy1j

• 数据库管理工具：NavicatPremium（点击下载，提取码：j18i）、HeidiSQL（官网下载地址）

.env.example 文件

.env 文件不应该加入版本控制，在 .env 里面添加修改了或删除了任何变量，请在 .env.example 里面同步更新，并写上注释

env 变量读取

代码中，严禁使用 env('xxx') 来获取变量，env 里面的变量都必须在 config/xxx.php 里面配置后，通过 config('xxx.xxx') 来获取，硬编码写死在代码里面是十分不明智的

说明：可以利用框架的加载缓存来提高速度、后期维护更加方便

辅助函数

如果有自定义的辅助函数等，一律存放在 app/ 或 app/Common 或 app/Tools 目录，只能存在一个地方，不允许出现多个目录都有

静态资源

用户上传的文件等，应该统一上云，链接入库，不允许 存在本地服务器

给用户上传文件权限应该做相应限制，云上的图片加上防盗链等，若有必要，云图片全部私有，查看图片需通过后台申请临时链接

页面不允许引入第三方静态资源，必须将静态资源下载到本地，或者上公司云后再进行引入

路由

路由中绝不允许使用闭包路由或其他，因为无法路由缓存

路由尽量要有前缀区分

路由尽量采用如下形式：命名空间-->前缀-->中间件-->分组 参考路由如下：

闭包

尽量少用闭包，用闭包也尽量控制在两层以内，超过两层

模型、数据库

三张表以上的查询，不允许使用 leftJoin 等连表查询，可用子查询代替或单独查出来后程序处理

模型

• 模型文件统一存放在 app/Models 中

• 模型无状态，切记，在模型中这个写法是不合适的 'user_id' => Auth::user()->id，应该将user_id入参传递过来

• 模型不应该跟业务有过多牵扯，它只负责取数据而已

数据库

• 数据库表创建，字段的修改，都必须用 migration 来创建，绝不允许通过图形化工具或命令行来直接修改数据库

• 数据库迁移文档：laravel数据库迁移文档

• 数据库表名创建必须为 复数

• 多个单词用下划线分割，如：user_class

• 表中必须要有created_at、updated_at字段（可通过$table->timestamps();生成），deleted_at字段（可通过$table->softDeletes();生成）根据需要添加

• 数据库主键，必须为 id，且要自增

控制器

• 记得一定要写注释（一般提议见名知意不写注释，我不赞同，因为需求是一直在变化的），注释主要写当初定下来的需求，有了逻辑需求，代码我相信大家都会写

表单验证

建议多看文档，要知道有哪些验证方法，不要求全记下来，至少用的时候要知道有这个验证规则 官方文档

如果不是有特别复杂且不会变的可重复利用的情况下，一般建议就直接在控制下进行表单验证，如下所示：

获取入参数据

将所有你需要的入参全部列出来，严禁 $request->all()

后续代码中严禁 where('name', $request->input('name')) 这样获取变量直接去查询或计算

# 将每一个变量单独拧出来，方便后期对该字段进行维护
$name = $request->input('name');
$age = $request->input('age');
......

# 或者
$data['name'] = $request->input('name');
$data['age'] = $request->input('age');
......

# 或者
$data = $request->only('name','age');

日期时间

必须使用 Carbon 来处理时间

laravel简单介绍

官方文档

日志

• 日志最好用 daily 来记录，保留最近三十天，如果可以的话，将日志打包存档

• 可以设计一个唯一 ID 来进行日志跟踪，只需要重写 Log 类即可

• 如果可能的情况下，将入参和出参都记录下来备查

• 日志记录级别一般情况下用 info，异常用 error，日志尽量用 __METHOD__.__FUNCTION__ 来作为日志键

异常

异常捕获中，不要直接将异常抛出（如数据信息等）给前端，给前端友好提示，异常发生时用 error 级别日志记录

返回格式

统一返回格式：

字段	类型	说明
code	int	状态码
msg	string	对状态的说明
success	bool	成功 true，失败 false
data	array 或 object	数据主体

说明：

• 不应该给前端过多的 http 状态码，没特殊情况，只有 200 或 非200 两种状态码

• code 说明：0 表示接口请求成功，业务正常成功处理，其他为业务处理失败（参数校验，业务处理中断等），业务处理失败时，msg 应有友好提示，前端直接展示即可

• msg 友好提示，成功或失败的补充说明

• success 布尔值，区分成功或失败

• data 成功后的响应主体，对象或数组

code 码

code 码的生成，有如下方案，根据具体情况选择合适的

行号

可以使用 __LINE__ 做为 code 码

号段

号段建议 10000 起，采用号段时，应该尽量使号段统一管理，而不是分散在代码各处，如下是推荐的做法