首先，我们知道，jwt生成的token形如aaa.bbb.ccc的字符串，但是为什么我们通常传输的是Bearer aaa.bbb.ccc呢，还要多次一举地添加上一个Bearer呢？
其实，这是一种规范。
规范解释
w3c规定，请求头Authorization用于验证用户身份。这就是告诉我们，token应该写在请求头Authorization中（当然你非要写在cookie，body或者写在url参数中也行，只要前后端开发约定好就行，但不建议）。那么互联网发展至今，认证方式也有很多种，所以w3c还规定，Authorization应当写成这样的形式Authorization: <type> <credentials>，type是指认证的方式，credentials则是认证需要的信息。所以才有了jwt token的标准写法Authorization: Bearer aaa.bbb.ccc。
举个例子加深理解
再举个例子加深理解，比如，一个人想进一扇门，那他首先需要开门（访问服务器资源首先要认证身份），但是开门的方式有很多种，可能是机械锁，也可能是密码锁。如果这个人想进这扇门，那么他需要两个信息，一是开门的方式type，二是开门的具体信息credentials。
- 所以他应当得到以下信息：
机械锁 钥匙藏在门垫下，通过这个信息，这个人就知道，只需要掀开门垫拿到钥匙就能进门。 - 而如果他得到的信息是：
密码锁 钥匙藏在门垫下，由于有type的存在，这个人并不会认为在门垫下会有一把钥匙，而是知道输入“钥匙藏在门垫下”这个字符串，就能打开门。
通过这里例子，我们可以知道，type的作用，就是告诉服务器如何去认证访问者的身份。如果服务器事先就已经知道了认证方式，那么有无Bearer都不影响认证结果。
是否有必要加上Bearer
那么加Bearer是否有还有必要，答案是有必要，因为Bearer不是给人看的，是给框架看的，有了规范才有框架。假设让你去开发一个自动认证的框架，这个框架要求能支持多种认证方式（认证方式除了Bearer之外，还有Basic，Basic就是指，把用户名和密码用冒号拼接起来，再用base64编码，形如base64(username:password)），你会怎么做？
那么一个可行的方案就是，自动从请求头中获取Authorization的值，然后用空格截取开头的字符串得到认证的方式type，然后再去调用对应的认证方法，比如authByBearer()或者authByBasic()。事实上，很多认证框架就是这么干的！
后话
很多规范的提出，都是为了方便编码，我们应当按照规范编写代码（即使不按照规范也能完成功能，也不该那么做）。因为规范，大概率是因为前人遇到了问题才提出的解决方案，从而演变来的。我们后人最初可能感到不解，但是随着知识面的加深，总会慢慢理解其中的奥妙。
