最佳实践

1、DRY（Don't Repeat Yourself）

2、命名路由

3、使用基类，比如请求验证类，授权策略类等

4、目录或者文件根据资源或者也逻辑进行切割区分，比如视图文件，服务类文件等等

5、上传文件三要素：目录，文件名，后缀。另外需要注意将文件夹切割能让查找效率更高，拼接文件名，加前缀是为了增加辨析度。

6、上传头像的时候，考虑到网站的整体美观，需要限制图片的分辨率，图片太大会拖慢页面加载速度。

7、数据库内容填充，一般生成假数据，如果要生成项目初始化数据，并且开发和生产环境都会用到，则考虑数据迁移方案。

8、因为 $fillable 属性允许用户直接对数据进行修改，在每一次开发数据模型的 CRUD 功能时，我们都要慎重地对 $fillable 属性进行定制。给自己提一个问题：『哪些字段我们将不允许用户直接修改？』

9、当一个新模型被初次保存将会触发 creating 以及 created 事件。如果一个模型已经存在于数据库且调用了 save 方法，将会触发 updating 和 updated 事件。在这两种情况下都会触发 saving 和 saved 事件。

10、我们提倡在控制器 Auth 中间件使用中，首选 except 方法，这样的话，当你新增一个控制器方法时，默认是安全的，此为最佳实践。

11、某一文件夹下的文件皆为用户上传的话题图片文件，我们需要防止这些文件被纳入 Git 版本控制器中，可以利用 Git 的 .gitignore 机制来实现。

12、作为一个合格的 Web 开发工程师，必须遵循一个安全原则：永远不要信任用户提交的数据。有两种方法可以避免 XSS 攻击：第一种，对用户提交的数据进行过滤；第二种，Web 网页显示时对数据进行特殊处理，一般使用 htmlspecialchars() 输出。

13、一般在做 xxx_count 此类总数缓存字段时，推荐动态计算总计数，然后再进行赋值。

14、在模型监听器中，数据库操作需避免再次触发 Eloquent 事件，以免造成联动逻辑冲突。所以这里我们使用了 DB 类进行操作。

15、权限的命名规范我们统一使用 _ 分隔法。

16、避免 Trying to get property of non-object 这种类似的错误发生，只需要在关联数据删除时，基于业务逻辑做联动删除即可。从实现的机制来看，可以有分以下两种类型：

• 代码监听器 —— 利用 Eloquent 监控器 的 deleted 事件连带删除，好处是灵活、扩展性强，不受底层数据库约束，坏处是当删除时不添加监听器，就会出现漏删；

• 外键约束 —— 利用 MySQL 自带的外键约束功能，好处是数据一致性强，基本上不会出现漏删，坏处是有些数据库不支持，如 SQLite。

如果使用的是 MySQL 或者其分支，我们一般会选择『外键约束』的方式来实现。当然，如果业务上有特殊的逻辑，就会优先考虑代码监听器的灵活性。

• 本地化

第一种方案（本地化完全交给客户端）比较专业，大部分的第三方 API 平台接口提供方都会提供状态码，如 新浪微博 错误码，但是你需要一个个地将错误码写出。在某些开发需求中，错误码可能不仅影响本地化，有时客户端需要服务器返回的特定状态码做不同的业务处理，比如跳转到不同的页面。

第二种方案（接口根据客户端语言切换错误信息）比较便捷，客户端可以直接将服务器的报错消息显示给用户，从快速实现的角度来看，省去了错误码的定义，并且后期可通过服务器代码来控制错误消息内容，也带来一定的灵活性。

从接口的可扩展性、适用性和专业性上考虑，最合理的也是最推荐的做法是将两种方案合并 —— API 既提供错误码，又提供错误消息。

另外，错误消息 默认 返回英文，也会是比较合理的最佳实践，当然最终视 API 业务逻辑而定。