下图是目录结构，感兴趣的同学可以花 ￥20 元学习一下（毕竟我写了两个周，就当请我喝杯咖啡啦）。
最近项目遇到一个情况，我们在遇到用户访问某个信息没有权限的时候，希望提示详细的原因，比如当访问一个团队资源时非成员访问的场景下会提示一个：您不是 [xxxxxx] 团队的成员，暂时无法查看，可<申请加入>，同时需要显示打码后的团队名称，以及加入按钮，可是接口方的逻辑是当没有权限时直接 abort 了：
abort_if(!$user->isMember($resouce->team), 403, '您无权访问该资源');
得到的响应结果如下：
HTTP/1.0 403 Forbidden
{
"message": "您无权访问该资源"
}
我们不可能将 message 用 html 来完成前端提示页的展示，这样耦合性太强，违背了前后端分离的原则。我们的目标是返回如下的格式即可解决：
HTTP/1.0 403 Forbidden
{
"message": "您无权访问该资源",
"team": {
"id": "abxT8sioa0Ms",
"name": "CoDesign****"
}
}
通过携带上下文的方法传递数据，方便了前端同学自由组合。
当然这并不是什么复杂的事情，直接修改原来的 abort_if 即可解决：
- abort_if(!$user->isMember($resouce->team), 403, '您无权访问该资源');
+ if (!$user->isMember($resouce->team)) {
+ return response()->json([
+ 'message' => '您无权访问该资源',
+ 'team' => [
+ 'id' => $resouce->team_id,
+ 'name'=> $resouce->team->desensitised_name,
+ ]
+ ], 403);
+ }
这样看起来解决了问题，可是试想一下，如果是在闭包里面检测到异常想要退出，上面这种 return 式的写法就会比较难搞了，毕竟 return 只会终止最近的上下文环境，我们还是希望像 abort 一样能终止整个应用的执行，再进行另一番改造。
看了 abort 源码，我发现它的第一个参数其实支持 \Symfony\Component\HttpFoundation\Response 实例，而上面👆我们 return 的结果就是它的实例，所以我们只需要改成这样就可以了：
if (!$user->isMember($resouce->team)) {
abort(response()->json([
'message' => '您无权访问该资源',
'team' => [
'id' => $resouce->team_id,
'name'=> $resouce->team->desensitised_name,
]
], 403));
}
新的问题来了，如果需要复用的时候还是比较尴尬，这段代码将会重复出现在各种有此权限判断的地方，这并不是我们想要的。
为了达到逻辑复用，我认证看了 \App\Exceptions\Handler 的实现，发现父类的 render 方法还有这么一个设计：
public function render($request, Throwable $e)
{
if (method_exists($e, 'render') && $response = $e->render($request)) {
return Router::toResponse($request, $response);
} elseif ($e instanceof Responsable) {
return $e->toResponse($request);
}
//...
所以，我们可以将这个逻辑抽离为一个独立的异常类，实现 render 方法即可：
$ ./artisan make:exception NotTeamMemberException
代码如下：
<?php
namespace App\Exceptions;
use App\Team;
class NotTeamMemberException extends \Exception
{
public Team $team;
public function __construct(Team $team, $message = "")
{
$this->team = $team;
parent::__construct($message, 403);
}
public function render()
{
return response()->json(
[
'message' => !empty($this->message) ? $this->message : '您无权访问该资源',
'team' => [
'id' => $this->team->id,
'name' => $this->team->desensitised_name,
],
],
403
);
}
}
这样一来，我们的逻辑就变成了：
if (!$user->isMember($resouce->team)) {
throw new NotTeamMemberException($resouce->team, '您无权访问该资源');
}
当然也可以简化为：
\throw_if(!$user->isMember($resouce->team), NotTeamMemberException::class, $resouce->team, '您无权访问该资源');
问题到这里总算以一个比较完美的方式解决了，如果你有更好的方案欢迎评论探讨。
]]>Ant Design Pro 是基于 UmiJS 构建的，所以，如果你在使用 UmiJS，方法是完全一样的。
$ yarn add tailwindcss postcss-import postcss-nested autoprefixer
src 下创建 tailwind.csssrc/tailwind.css
@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';
在 config/config.js 中增加配置项 extraPostCSSPlugins：
//...
extraPostCSSPlugins: [
require('postcss-import'),
require('tailwindcss'),
require('postcss-nested'), // or require('postcss-nesting')
require('autoprefixer'),
],
//...
你可以在你觉得合适的地方全局引入上面创建的 tailwind.css，比如在 src/global.less 中引入：
@import '~antd/es/style/themes/default.less';
@import 'tailwind.css';
//...
然后你就可以在我们的页面使用了：
<div className="mt-4">
<div className="mb-3">
...
好了，搞定！
]]>如果我们给 ID 为 1 的文章打上两个标签，数据库标签关系表的的存储结果就是这样子：
> select * from taggables;
+--------+-------------+---------------+
| tag_id | taggable_id | taggable_type |
+--------+-------------+---------------+
| 1 | 1 | App\Post |
| 2 | 1 | App\Post |
+--------+-------------+---------------+
相信有不少人和我一样希望 taggable_type 的值不要直接用模型类名，而是使用表名：posts。官方文档的建议是：
use Illuminate\Database\Eloquent\Relations\Relation;
Relation::morphMap([
'posts' => 'App\Post',
'videos' => 'App\Video',
]);
https://laravel.com/docs/6.x/eloquent-relationships#custom-polymorphic-types
我们可以将这个定义写到 AppServiceProvider 中，但是有一个非常严重的问题：我们在新增或者删除模型的时候，会很容易忘记去更新这个定义。我已经至少出现这个问题 3 次了，所以我一直在纠结有没有更好的方法，今天突然灵机一动，实现了一个看起来似乎是一个不错的方式，分享给大家。
我尝试跟踪了一遍源码，发现模型中有一个方法 getMorphClass，多态关联的时候，就是用它来取目标对象的类型名称的，默认返回类名：
public function getMorphClass()
{
$morphMap = Relation::morphMap();
if (! empty($morphMap) && in_array(static::class, $morphMap)) {
return array_search(static::class, $morphMap, true);
}
return static::class;
}
那么，只要我们在模型中覆盖这个方法便可以方便的实现目标了。
我们有两个选择去实现它：
我当然会选择 trait 方式来实现，不管从定义还是代码耦合度上，使用 trait 来解决这类特性需求都是再适合不过了，如果你对 trait 还不太熟悉，可以阅读我之前的文章：《我所理解的 PHP Trait》
我们的目标是使用表名来做为关系类别名，那么在模型中如何获取表名呢，直接使用模型的 getTable 即可，那么整个 trait 的实现如下：
app/Traits/UseTableNameAsMorphClass.php
<?php
namespace App\Traits;
trait UseTableNameAsMorphClass
{
public function getMorphClass()
{
return $this->getTable();
}
}
然后在我们需要用到关系类型的模型中引入它即可：
<?php
namespace App;
use App\Traits\UseTableNameAsMorphClass;
use Illuminate\Database\Eloquent\Model;
class Post extends Model
{
use UseTableNameAsMorphClass;
//...
}
当然，如果你习惯给表名加前缀，或者你的表名与模型名不太一致，那么，你只需要修改 trait 中 getMorphClass 的实现即可，我个人的习惯是模型名就是表名的单数，不带前缀。
如果你有更好的实现方式，欢迎留言交流。
]]>下图是目录结构，感兴趣的同学可以花 ￥20 元学习一下（毕竟我写了两个周，就当请我喝杯咖啡啦）。
tokensExpireIn 对此类 token 无效，原文如下：
Personal access tokens are always long-lived. Their lifetime is not modified when using the tokensExpireIn or refreshTokensExpireIn methods.
默认时间为 1 年，但是这可能不满足我们的需求，我们想要改成其它更短的时间怎么办呢？今天尝试了一下，应该算是全网可以找到的最简单方法了，直接在 app/Providers/AppServiceProvider 中添加一句就可以搞定，下面以改为有效期为 1 周的示例来演示：
app/Providers/AppServiceProvider.php
<?php
//...
use Laravel\Passport\Bridge\PersonalAccessGrant;
use League\OAuth2\Server\AuthorizationServer;
//...
class AppServiceProvider extends ServiceProvider
{
/**
* Bootstrap any application services.
*/
public function boot()
{
$this->app->get(AuthorizationServer::class)
->enableGrantType(new PersonalAccessGrant(), new \DateInterval('P1W'));
}
//...
}
//...
关于时间值的写法，请参考:
]]>https://secure.php.net/manual/en/dateinterval.construct.php
其实网上有相当多的关于 Deployer 的使用教程，在这个社区也有不少同学写过，不过发现很难找到一个完整能跑通的文章，所以希望今天写这篇是一个小白就能完整走通的教程吧，当然了，这是回忆加参考外文写出来的，难免也有失误，欢迎小白同学在下面反馈使用过程中遇到的问题为谢！
在开始之前，有必要了解一下 Deployer 是一个什么样的东西。
Deployer 是一个基于 SSH 协议的无侵入 web 项目部署工具，因为它不需要你在目标服务器上装什么服务之类的东西即可使用，它只需要在你的开发机，或者你的笔记本，就是发起部署动作的一方安装即可。
它的原理就是通过 SSH 到你的机器去创建目录，移动文件，执行指定的动作来完成项目的部署。
我画了一张图来说明它的操作原理：
绘图工具：https://www.draw.io/
简单介绍一下，Deployer 安装在本地，它通过 SSH 协议登录到服务器 web server 上执行一系列我们预定的操作，其中包含从代码库 Git Server 拉取我们的项目代码部署到 web 服务器指定的目录完成部署。
一共分为以下几个部分：
我们分开一个个讲，在后面的每一步请注意区分当前逻辑所在的环境：本地 / 目标服务器。
此部分在本地操作
Deployer 是一个 composer 包，你可以选择以 phar 包的形式，或者以 composer 全局安装来使用它，这里只讲后者，毕竟这是推荐大家使用的方式，升级也会方便很多：
$ composer global require deployer/deployer -vvv
安装完成你应该可以使用以下命令来查看它的版本信息：
$ dep --version
# Deployer master
如果提示 dep 命令不存在的话，可能需要将 composer 的 bin 目录加到你的 PATH 环境变量里面，通常是家目录下的 .composer/vendor/bin/，你可以通过下面的命令来查看是否配置成功：
$ echo $PATH
/usr/local/sbin /usr/local/bin /Users/overtrue/.composer/vendor/bin
Mac 环境下根据你使用 shell 的不同来配置环境变量，默认的 bash 的话直接编辑家目录下的 .bash_profile 文件即可：
$ vim ~/.bash_profile
# 将 composer bin 目录加到其中即可
# export PATH=/usr/local/bin:/Users/overtrue/.composer/vendor/bin:$PATH
# 然后保存退出
然后切一个新的终端窗口，应该就有 dep 命令了。
Deployer 的安装就到这里，接下来我们去目标服务器去折腾一下。
此部分在目标服务器上操作
虽然说是无侵入的部署工具，但是还是需要我们来做一些微小的配置的，因为出于安全考虑，我们一般不会开发 root 用户的 SSH 登录，而是使用其它用户，比如 Ubuntu 默认的 ubuntu 用户。
我们 Deployer 是用来部署 web 应用的，所以我们也专门创建一个用户来做这件事情比较好：
$ sudo adduser deployer
# 密码什么的，按提示操作即可
我们的 web 项目通常需要一些上传，或者缓存写入这样的操作，所以 deployer 还需要有权限对目录进行修改，比如 Laravel 的 storage 目录需要可写权限，这里以 nginx 默认的用户组 www-data 举例，如果你修改过用户或者组名请对应修改下面的命令里的 www 用户组：
$ sudo usermod -aG www-data deployer
我们通常需要将deployer 用户权限分别设置为创建文件 644 与目录 755，这样一来，deployer 用户可以读写，但是组与其它用户只能读：
$ su deployer # 切换到 deployer 用户
$ echo "umask 022" >> ~/.bashrc
$ exit # 退出
我们需要将 depoloyer 用户加到 sudoers 中：
$ vim /etc/sudoers
# 在最后加入
deployer ALL=(ALL) NOPASSWD: ALL
# 保存并退出
接下来要对我们的 web 根目录授权，假设我们的 web 服务的根目录在 /var/www/ 下，那么需要将这个目录的用户设置为 deployer ，组设置为 www 用户 www-data:
$ sudo chown deployer:www-data /var/www/html # 最后这里不要加斜线哦
为了让 deployer 用户在 /var/www/html 下创建的文件与目录集成根目录的权限设定（用户：deployer,组：www-data），我们还需要一步操作：
$ sudo chmod g+s /var/www/html
OK，Deployer 的用户操作就结束了，接着你需要检查以下配置：
deployer 后执行）：php -v，如果报错的话，一般建议是将 php 的 bin 文件软链接到 /usr/local/bin/（推荐） 或者 /usr/bin/ 下。npm,nginx,composer 都在 deployer 用户下可以使用，否则在部署的时候会出错。此部分在目标服务器上操作
我们 deployer 的运行机制是从 git 或者其它你指定的代码库 clone 代码到目标服务器，所以如果你的代码不是公开的仓库，我们通常需要添加 SSH 公钥才可以从代码库 clone 代码，所以接着来创建公钥：
先切换当前登录用户到 deployer：
$ su - deployer
然后创建 SSH 密钥：
$ ssh-keygen -t rsa -b 4096 -C "deployer"
# 这里的 -C 是指定备注
# 一路回车下去即可
然后我们将生成的公钥拷贝出来：
$ cat ~/.ssh/id_rsa.pub # 显示公钥
请完整的复制 cat 出来的结果，然后去你的代码库添加 SSH 公钥。
OK, 现在你的服务器就可以从代码库 clone 代码了，你可以在服务器上 git clone 一下你的代码库测试，如果不成功，请检查你的公钥是否正确完全的复制与粘贴正确，不正确的话再次重复复制粘贴即可。
此部分在本地（或者开发机）操作
在本地（或者开发机）执行部署任务时我们不想每次输入密码，所以我们需要将 deployer 用户设置 SSH 免密码登录：
在本机生成 deployer 专用密钥，然后拷贝公钥：
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/deployerkey
然后将公钥保存到目标服务器（注意，这一步还是在本机操作）：
$ ssh-copy-id -i ~/.ssh/deployerkey.pub deployer@123.45.67.89 # 请填写服务器 IP
# 应该会让你输入 deployer 在服务器上的登录密码，输入后回车即可
然后你应该就可以直接以 deployer 用户免密码登录到服务器了，测试方式：
$ ssh deployer@123.45.67.89 -i ~/.ssh/deployerkey
# 应该就能直接进到服务器上了，然后 exit 退出
OK，这一步搞定了 deployer 免密码登录，接下来我们聊项目的部署。
这些都在本地操作哦
假设我们的项目在本地 /www/demo-project 下，那么我们切换到该目录：
$ cd /www/demo-project
然后执行 Deployer 的初始化命令：
$ dep init
它会让你选择项目类型，比如 Laravel，symfony 等，如果你都不是，选择 common 类型即可。
这一步操作将会在当前目录生成一个 deploy.php 文件，这个文件就是部署清单，也就是告诉 Deployer 怎样去部署你的项目，关于这部分我们不需要过多的介绍，大家去参考 Deployer 官网的详细说明操作即可。
需要关心的几个配置是：
// 指定你的代码所在的服务器 SSH 地址，请不要使用 https 方式哦。
set('repository', 'git@mygitserver.com:overtrue/demo-project.git');
// 这里填写目标服务器的 IP 或者域名
host('your_server_ip')
->user('deployer') // 这里填写 deployer
// 并指定公钥的位置
->identityFile('~/.ssh/deployerkey')
// 指定项目部署到服务器上的哪个目录
->set('deploy_path', '/var/www/demo-app');
正确填写完配置清单以后，我们就可以部署我们的项目了，确认你的代码已经提交到代码仓库，因为执行部署的时候并不是将当前代码部署到服务器，而是从代码库拉最新的版本。
然后在当前目录执行：
$ dep deploy -vvv
就可以看到整个部署过程了，一般正常会是像下面这样子：
$ dep deploy -vvv
Deployer's output
✈︎ Deploying master on your_server_ip
✔ Executing task deploy:prepare
✔ Executing task deploy:lock
✔ Executing task deploy:release
➤ Executing task deploy:update_code
✔ Ok
✔ Executing task deploy:shared
✔ Executing task deploy:vendors
✔ Executing task deploy:writable
✔ Executing task artisan:storage:link
✔ Executing task artisan:view:clear
✔ Executing task artisan:cache:clear
✔ Executing task artisan:config:cache
✔ Executing task artisan:optimize
✔ Executing task deploy:symlink
✔ Executing task deploy:unlock
✔ Executing task cleanup
Successfully deployed!
如果失败的话就需要检查一下哪一步出错了，通常根据报错信息即可定位。
Deployer 部署完成后，在服务器上的结构会是这样子：
drwxr-sr-x 5 deployer www-data 4096 Jun 14 09:53 ./
drwxr-sr-x 6 deployer www-data 4096 Jun 11 14:25 ../
drwxr-sr-x 2 deployer www-data 4096 Jun 14 09:53 .dep/
lrwxrwxrwx 1 deployer www-data 10 Jun 14 09:52 current -> releases/7/
drwxr-sr-x 4 deployer www-data 4096 Jun 14 09:53 releases/
drwxr-sr-x 3 deployer www-data 4096 Jun 10 14:16 shared/
其中，.dep 为 Deployer 的一些版本信息，不用去研究，我们需要关心的是下面这几个：
current - 它是指向一个具体的版本的软链接，你的 nginx 配置中 root 应该指向它，比如 laravel 项目的话 root 就指向：/var/www/demo-app/current/publicreleases - 部署的历史版本文件夹，里面可能有很多个最近部署的版本，可以根据你的配置来设置保留多少个版本，建议 5 个。保留版本可以让我们在上线出问题时使用 dep rollback 快速回滚项目到上一个版本。shared - 共享文件夹，它的作用就是存储我们项目中版本间共享的文件，比如 Laravel 项目的 .env 文件，storage 目录，或者你项目的上传文件夹，它会以软链接的形式链接到当前版本中。OK，那基本上这样子就完成了整体 Deployer 需要考虑的地方以及使用细节了，相信大部分同学的问题都出在权限问题上。所以上面在创建用户时，一定要仔细操作。
Deployer 确实非常好用，一条命令完成部署，回滚等操作，但是它目前还不是很完美，大家有问题可以去 GitHub 官方仓库提 issue 或者搜索相关问题解决方案。
个人用它已经两年了，非常喜欢这样简单的部署方式，但是新手刚用的时候难免在服务器权限这块碰壁不少，我总结了以下几个建议：
Composer 对你来说已经相当熟悉了，不过对于包的版本，我觉得应该还有不少同学不是那么清楚各种写法到底是啥意思。
首先，我们来了解一个东西：语义化版本
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
语义化版本一般我们使用 3 个部分来表示一个版本，例如：1.4.23，1 为主版本号，4 为次版本号，23 为修订号或者补丁版本号。当然你肯定也见过 1.0.0-alpha1 这样在后面添加修饰符号来表示先行版本。
那在 composer 使用过程中我们通常会有这几种写法：
极不推荐这样玩哦
使用 * 号来表示版本的时候，composer 会根据你配置中的 minimum-stability 的值情况来决定安装最新的 dev 还是 stable 版本。
比如：
"require": {
"overtrue/wechat": "*"
}
根据上面语义化版本的定义，这样写就相当于允许大版本的安装，那你的代码在 composer 更新依赖后可能就跑不起来了（如果第三方包作者做了大版本更新）。
dev- 前缀加分支名我们在自己开发一个包的时候，经常会用 dev-master 或者 dev-develop 来指定版本，它表示使用该分支下最新的提交。
比如：
"require": {
"overtrue/wechat": "dev-master"
}
这个也是不推荐在生产环境使用的，因为它其实与 * 没有太大的差别，不过 * 在 minimum-stability 为 stable 时是安装最新的稳定版。但是二者都无法保证 API 兼容性。
~ 约束符锁定小版本的方式这种方式比较常用，也是比较安全的，比如我们希望安装 >= 1.2 并且 < 2.0 的版本时，根据语义化版本的定义，次版本号的变化是新增功能，所以 API 是稳定的，也就是可以安全更新的。
你可以写成：
"require": {
"overtrue/wechat": "~1.2"
}
如果你希望次版本都不要更新，只允许修订版本（补丁版本）的变化，>= 1.1.15 并且 < 1.2.0，则写成：
"require": {
"overtrue/wechat": "~1.1.15"
}
所以，你应该看出规律了，~ 的作用是允许表达式中最后一位变到最大值，~1.1 表示可以为 大于等于 1.1 的任何版本，比如 1.1.0、1.2.0、1.3.5 、1.99.9999、 1.9999.999999 都可以安装，但是不能安装 2.0.0， 同理，~1.1.2 表示 大于等于 1.1.2 的任何版本，比如 1.1.2、1.1.3、1.1.99、 1.1.9999 都可以安装。
^ 约束符锁定大版本上面 ~ 表示最后一位可变，前面几位都不可变，那 ^ 的作用不一样的是：^ 锁定不允许变的第一位，其实学过正则的同学都知道 ^ 表示起始，^a 表示以 a 开头的全部。
所以， ^1.2 表示任意大于等于 1.2 的 1.x.x 版本，比如 1.2.0、1.2.1、1.3.0、1.9.99999 等。只要前面的 1 并且大于 ^ 后面指定的 1.2 都满足条件。
有时候我们的使用场景要求只能安装某些版本范围内的时候，可以使用 >、<、>=、<=、| 这些符号来组合，比如：>= 1.3 <1.6、>=1.3 | >=1.7 、3.0|4.0 等。这样的使用场景并不多，根据你的情况来调整用法就好。
使用 =1.2.34 或者 1.2.34 都是指定了具体的版本号， composer 不会考虑检查新版本来安装。
如果你的版本是 1.0 以下，0.0.1，0.9.99999 等这样的版本的时候， ^ 的作用与 ~ 一样，也就是说：
^0.0.3 表示：>=0.0.3 < 0.0.4
所以需要注意这个问题，之所以这样设计是有原因的：主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。
所以不要掉进这个坑哦。
无论你是包的作者，还是使用者，正确使用版本是非常重要的，尤其对于有一定使用量的包作者来讲，严格遵守语义化版本的规范是对你的用户负责。最后引入 semver.org 官网的一句话：
]]>记住， 语义化的版本控制就是透过版本号的改变来传达意义。若这些改变对你的使用者是重要的，那就透过版本号来向他们说明。
net::ERR_INCOMPLETE_CHUNKED_ENCODING 的报错。
为了将其改为上传到服务器端然后插入 img 标签的形式，我们需要做一些小小的自定义，下面的一段简单的代码即可达到此目的：
jQuery(document).ready(function($) {
//upload image in description
$('#description').summernote({
height: 300,
callbacks: {
onImageUpload: function(files, editor, welEditable) {
for (var i = files.length - 1; i >= 0; i--) {
sendFile(files[i], this);
}
}
}});
//create record for attachment
function sendFile(file, el) {
data = new FormData();
data.append("file", file); // 表单名称
$.ajax({
type: "POST",
url: "这里填写你的服务器端上传 URL",
data: data,
cache: false,
contentType: false,
processData: false,
dataType: 'json',
success: function(response) {
// 这里可能要根据你的服务端返回的上传结果做一些修改哦
$(el).summernote('editor.insertImage', response.url, response.filename);
},
error : function(error) {
alert('图片上传失败');
},
complete : function(response) {
}
});
}
});
Trait 是为类似 PHP 的单继承语言而准备的一种代码复用机制。Trait 为了减少单继承语言的限制，使开发人员能够自由地在不同层次结构内独立的类中复用 method。Trait 和 Class 组合的语义定义了一种减少复杂性的方式，避免传统多继承和 Mixin 类相关典型问题。
Trait 和 Class 相似，但仅仅旨在用细粒度和一致的方式来组合功能。 无法通过 trait 自身来实例化。它为传统继承增加了水平特性的组合；也就是说，应用的几个 Class 之间不需要继承。
其实说通俗一点，就是能把重复的方法拆分到一个文件，通过 use 引入以达到代码复用的目的。
那么，我们应该怎么样去拆分我们的代码才是合适的呢？我的看法是这样的：
Trait，译作 “特性”、“特征”、“特点” 。那么问题就来了：什么才是特性？
一个销售公司有很多种产品：电视，电脑与鼠标垫，卡通手办等。其中鼠标垫与卡通手办是非卖品，只用于赠送。
那么这里的 “可卖性” 就是一个特性，非卖品是没有价格的。我们便可以抽象出 “可卖性” 这个 Trait 来：
trait Sellable
{
protected $price = 0;
public function getPrice()
{
return $this->price;
}
public function setPrice(int $price)
{
$this->price = $price;
}
}
当然我们所有的产品都会有品牌与其它基本属性，所以我们通常会定义一个产品类：
class Pruduct
{
protected $brand;
//...
public function __construct($brand)
{
$this->brand = $brand;
}
public function getBrand()
{
return $this->brand;
}
//...
}
我们的电视与电脑类：
class TV extends Pruduct
{
use Sellable;
//...
public function play()
{
echo "一台 {$this->brand} 电视在播放中...";
}
//...
}
class Computer extends Pruduct
{
use Sellable;
protected $cores = 8;
//...
public function getNumberOfCores()
{
return $this->cores;
}
//...
}
而鼠标垫与手办等礼品是不可卖的：
class Gift extends Pruduct
{
protected $name;
function __construct($brand, $name)
{
parent::__construct($brand);
$this->name = $name;
}
//...
}
上面的这个例子中，“可卖性” 便是部分商品的一个特性，也可以理解为商品的一个归类。你也许会说，我也可以再添加一个 Goods 类来完成上面的例子啊，Goods 继承 Product，再让所有可卖的商品继承于 Goods 类，把价格属性与方法写到 Goods 里，同样可以代码复用啊。的确，这没啥问题。但是你会发现：你有多个需要区别的特性时，由于 PHP 只有单继承的原因，你不得不组合很多个基类出来，将他们层叠，最终得到的树状结构是很复杂的。这也是 Trait 所带来的优势：随意组合，代码清晰。
其实还有很多例子，比如可飞行的，那么把飞行这个特性所具有的属性（如：高度，距离）与方法（如：起飞，降落）放到一个 trait 就是一个合理的拆分。
trait 有什么优势？来看一段代码：
class User extends Model
{
use Authenticate, SoftDeletes, Arrayable, Cacheable;
...
}
这个用户模型类，我们引入了四个特性：注册与授权、软删除、数组式操作、可缓存。
我们看到代码的时候一眼便知道当前支持了哪些个特性。再看下面另外一种写法：
abstract AdvansedUser {
// ... 实现了 Authenticate, SoftDeletes, Arrayable, Cacheable 的所有方法
}
class User extends AdvansedUser
{
...
}
你不得不再去阅读 AdvansedUser 的代码才能理解。你想说没有可读性是因为我基类的名称没起好？可是，这种各种特性组合的一个基类是根本无法起一个见名知义的名称的，不信你可以试一下。
就算你真的起了一个见名知义的名称：AuthenticateCacheableAndArrayableSoftDeletesUser，可是当需求变更，要求在 FooUser（同样继承了这个基类） 中去除缓存特性，而 User 类保留这个特性，怎么办？再创建一个基类么？
这就是我理解的 Trait：
它不仅仅是可复用代码段的集合，它应该是一组描述了某个特性的的属性与方法的集合。它的优点在于随意组合，耦合性低，可读性高。
平常写代码的时候也许怎么拆分才是大家的痛点，分享以下几个技巧：
总之一定要记住：不要为了让两段相同的代码提到一起这样简单粗暴的方式来拆分。
以上是个人见解，欢迎各位讨论。😄
]]>https://bitbucket/xxxx, 没有代理的话还是会卡在这里。
我们可以使用 bitinn/kneesocks 来支持 npm 的 socket 代理，它的作用按我的理解是生成一个本地的 HTTP 代理。
安装：
$ npm install kneesocks --production -g
创建本地代理：
kneesocks PORT1 PORT2
这里需要说明一下，PORT1 为一个未被使用的新端口，用于 kneesocks 监听，PORT2 是已经存在的本地代理，比如我们已经安装的 ss 的本地端口。
例如：kneesocks 1082 1080, 1080 为本地 ss 端口。
配置 npm 代理：
$ npm config set http http://127.0.0.1:1082
$ npm config set https-proxy http://127.0.0.1:1082
注意，使用 kneesocks 端口
然后你就可以正常的 npm install 了。
如果你后面想去掉代理：
$ npm config delete http
$ npm config delete https-proxy
DEBUG 代理，使用以下命令：
DEBUG=proxy kneesocks PORT1 PORT2