java代码翻译器手机版-java翻译器软件下载手机版 收藏 0

编译和解释的区别是什么

编译器是把源程序的每一条语句都编译成机器语言,并保存成二进制文件,这样运行时计算机可以直接以机器语言来运行此程序,速度很快;

而解释器则是只在执行程序时,才一条一条地解释成机器语言给计算机来执行,所以运行速度是不如编译后的程序运行得快的.

这是因为计算机不能直接认识并执行我们写的语句,它只能认识机器语言(是二进制的形式)

一、低级语言与高级语言

最初的计算机程序都是用0和1的序列表示的，程序员直接使用的是机器指令，无需翻译，从纸带打孔输入即可执行得到结果。后来为了方便记忆，就将用0、1序列表示的机器指令都用符号助记，这些与机器指令一一对应的助记符就成了汇编指令，从而诞生了汇编语言。

无论是机器指令还是汇编指令都是面向机器的，统称为低级语言。因为是针对特定机器的机器指令的助记符，所以汇编语言是无法独立于机器(特定的CPU体系结构)的。

但汇编语言也是要经过翻译成机器指令才能执行的，所以也有将运行在一种机器上的汇编语言翻译成运行在另一种机器上的机器指令的方法，那就是交叉汇编技术。

高级语言是从人类的逻辑思维角度出发的计算机语言，抽象程度大大提高，需要经过编译成特定机器上的目标代码才能执行，一条高级语言的语句往往需要若干条机器指令来完成。

高级语言独立于机器的特性是靠编译器为不同机器生成不同的目标代码(或机器指令)来实现的。那具体地说，要将高级语言编译到什么程度呢，这又跟编译的技术有关了，既可以编译成直接可执行的目标代码，也可以编译成一种中间表示，然后拿到不同的机器和系统上去执行，这种情况通常又需要支撑环境，比如解释器或虚拟机的支持，Java程序编译成bytecode，再由不同平台上的虚拟机执行就是很好的例子。

所以，说高级语言不依赖于机器，是指在不同的机器或平台上高级语言的程序本身不变，而通过编译器编译得到的目标代码去适应不同的机器。从这个意义上来说，通过交叉汇编，一些汇编程序也可以获得不同机器之间的可移植性，但这种途径获得的移植性远远不如高级语言来的方便和实用性大。

二、编译与解释

编译是将源程序翻译成可执行的目标代码，翻译与执行是分开的；而解释是对源程序的翻译与执行一次性完成，不生成可存储的目标代码。这只是表象，二者背后的最大区别是：对解释执行而言，程序运行时的控制权在解释器而不在用户程序；对编译执行而言，运行时的控制权在用户程序。

解释具有良好的动态特性和可移植性，比如在解释执行时可以动态改变变量的类型、对程序进行修改以及在程序中插入良好的调试诊断信息等，而将解释器移植到不同的系统上，则程序不用改动就可以在移植了解释器的系统上运行。同时解释器也有很大的缺点，比如执行效率低，占用空间大，因为不仅要给用户程序分配空间，解释器本身也占用了宝贵的系统资源。

编译器是把源程序的每一条语句都编译成机器语言,并保存成二进制文件,这样运行时计算机可以直接以机器语言来运行此程序,速度很快;而解释器则是只在执行程序时,才一条一条地解释成机器语言给计算机来执行,所以运行速度是不如编译后的程序运行得快的.

• 编辑：用编辑软件（EDIT.EXE或记事本）形成源程序（.ASM）,如：LX.ASM;
• 汇编：用汇编程序（MASM.EXE）对源程序进行汇编，形成目标文件（.OBJ），格式如下：MASM LX.ASM;
• 连接：用连接程序（LINK.EXE）对目标程序进行连接，形成可执行文件（.EXE），格式如下：LINK LX.OBJ;
• 执行：如果结果在屏幕在显示，则直接执行可执行文件。
• 调试：用调试程序（DEBUG.EXE）对可执行文件进行调试，格式如下：DEBUG LX.EXE

1.在具体计算机上实现一种语言，首先要确定的是表示该语言语义解释的虚拟计算机，一个关键的问题是程序执行时的基本表示是实际计算机上的机器语言还是虚拟机的机器语言。这个问题决定了语言的实现。根据这个问题的回答，可以将程序设计语言划分为两大类：编译型语言和解释型语言。

2. 由编译型语言编写的源程序需要经过编译、汇编和链接才能输出目标代码，然后机器执行目标代码，得出运行结果，目标代码由机器指令组成，一般不能独立运行，因为源程序中可能使用了某些汇编程序不能解释引用的库函数，而库函数代码又不在源程序中，此时还需要链接程序完成外部引用和目标模块调用的链接任务，最后输出可执行代码。C、C++、Fortran、Pascal、Ada都是编译实现的。

3. 解释型语言的实现中，翻译器并不产生目标机器代码，而是产生易于执行的中间代码，这种中间代码与目标机器代码是不同的，中间代码的解释是由软件支持的，不能直接使用硬件，软件解释器通常会导致执行效率较低。用解释型语言编写的程序是由另一个可以理解中间代码的解释程序执行的。与编译程序不同的是，解释程序的任务是逐一将源程序的语句解释成可执行的机器指令，不需要将源程序翻译成目标代码后再执行。对于解释型Basic语言，需要一个专门的解释器解释执行 Basic程序，每条语言只有在执行才被翻译。这种解释型语言每执行一次就翻译一次，因而效率低下。

4. Java很特殊，Java程序也需要编译，但是没有直接编译称为机器语言，而是编译称为字节码，然后在Java虚拟机上用解释方式执行字节码。Python 的也采用了类似Java的编译模式，先将Python程序编译成Python字节码，然后由一个专门的Python字节码解释器负责解释执行字节码。

(Java虚拟机对字节码的执行相当于模拟一个cpu，而ruby1.8–在虚拟机还未出现前–是通过解释成语法树执行。)

以上就是编译和解释的区别是什么的详细内容，更多请关注其它相关文章！

鸿蒙系统，引领未来！

在当下的手机市场中，华为鸿蒙系统无疑是备受瞩目的焦点。自从它诞生以来，就承载着众多用户以及整个行业的高度关注，大家都对这款国产操作系统充满了好奇与期待。

一方面，在外部环境诸多限制，特别是面对国外技术封锁的大背景下，华为鸿蒙系统的出现犹如一颗闪耀的新星，给国产操作系统领域带来了新的希望，让大家看到了国产科技打破国外垄断、实现自主创新的可能性。许多用户都迫切地想知道，鸿蒙系统到底有着怎样的表现，能否在日常使用中带来不一样的体验，是否真的能与那些早已深入人心的国外操作系统一较高下。

另一方面，随着智能手机在人们生活中扮演的角色越来越重要，操作系统作为手机的 “灵魂”，其性能、功能、易用性等各方面都直接影响着用户的使用感受。鸿蒙系统宣传中的诸多亮点，比如分布式能力、全场景应用、更安全高效等特性，更是吊足了大家的胃口，使得众多用户都期待着能看到专业详细的测评，好切实了解它在实际使用中的真实情况。

基于此，今天我就来给大家分享一下对华为鸿蒙系统的实测体验，从多个方面带大家深入了解这款备受关注的操作系统究竟有着怎样的魅力。

华为鸿蒙系统在版本更新方面堪称 “劳模”，更新速度十分惊人。就拿鸿蒙 NEXT 原生鸿蒙操作系统来说，自启动 Beta 测试以来，仅 120 余天的公测期就历经了 15 次大版本迭代，按照华为公布的版本更新时间表，其更新频率近乎每周一次大版本推送。而且不同机型收到的更新包大小也各有差异，像一些高端机型可能更新包会相对大些，旧一点的机型更新包大小或许会小一点，但都在不断接受着系统的优化升级。

不仅是鸿蒙 NEXT，其他版本的鸿蒙系统也是如此，比如之前华为为 Mate 50 系列手机推出的鸿蒙 OS 3.0.0.302 版本更新，虽然版本号变化不大，可在性能方面的提升却非常强势，使得华为 Mate 50 系列的 CPU 频率有了显著飙升。可以看出，华为工程师团队一直在全力优化系统体验，让鸿蒙系统处于持续成长、不断完善的过程中，致力于为用户提供更优质的使用感受，也彰显了华为在操作系统领域深耕细作、精益求精的决心。

鸿蒙系统每次更新都会带来诸多令人眼前一亮的变化，以鸿蒙 NEXT 版本为例，在控制中心方面，下拉后用户会发现更多大图标映入眼帘，并且在如鸿蒙 NEXT.0.0.72 版本中，还对控制中心界面进行了全新设计，让亮度条、音量条等控制元素更加直观、清晰，甚至新增了一键锁屏服务卡片等实用功能，使用起来更加便捷。

相册功能也有了细节改变，原本的选择按钮位置发生了变动，在鸿蒙 NEXT 里被放置在了右上角，用户需要先点击该按钮再进行全选或多选操作，照片长按还变为类似 iOS 的二级菜单，和以往的操作方式有所不同。

相机同样迎来了不少优化，比如将变焦刻度设计成了半圆的感觉，并保留了震动反馈；升级鸿蒙 OS NEXT 5.0.0.107 后，相机更是支持连拍熄屏快拍、笑脸抓拍等实用功能，还新增了前置自拍环形补光效果。而且 AI 摄影大师功能虽然按钮不见了，但其实是改为相机默认支持状态，相机会自动识别拍摄场景，辅助智能调色，让随手拍的照片质量更高。此外，像在锁屏界面左下角，鸿蒙 NEXT 集成了多个快捷功能按钮，方便用户快速操作一些常用功能。这些更新后的变化，都实实在在地给用户带来了不一样的操作感受和使用体验，让大家看到了鸿蒙系统不断进化的活力与魅力。

在流畅度方面，鸿蒙系统的表现可圈可点。就拿华为 Mate60 Pro 以及 Mate70 系列等机型来说，在日常使用中，连续开启多个常用软件，例如同时打开社交软件、办公软件以及浏览器等，鸿蒙系统都能快速响应，各个软件几乎瞬间就能完成启动，切换后台任务时也是相当顺滑，丝毫没有卡顿的感觉。

运行大型游戏时，其流畅度优势更为凸显。像一些对配置要求较高的大型手游，在鸿蒙系统的加持下，画面加载迅速，游戏过程中帧率稳定，操作跟手，能够让玩家畅快淋漓地享受游戏乐趣。与部分其他操作系统相比，鸿蒙系统在资源调度上似乎更为合理高效，能充分发挥手机硬件的性能，即使长时间游戏，也不容易出现掉帧、卡顿等影响游戏体验的情况，整体流畅度表现很是出色。

日常使用中，鸿蒙系统展现出了较高的稳定性。正常的接打电话、收发信息、浏览网页等操作，手机都能平稳运行，很少会出现意外的卡顿或者闪退现象。

在高强度测试下，比如长时间连续使用多个功能，或者同时运行多个占用资源较大的程序后，鸿蒙系统的发热情况控制得相对较好。以 Mate60 Pro 为例，经过一系列复杂操作后，其机身温度虽会有所上升，但仍在可接受范围内，并且不会因为发热而导致明显的卡顿。不过，在更新后的短时间内，偶尔会有个别应用出现短暂的适配问题，像是加载稍慢一点，但一般经过短时间的磨合，或者等待后续小版本更新优化后，就能恢复正常。而长时间使用后，系统整体的稳定性依然能保持在一个不错的水平，不会随着使用时长的增加就频繁出现故障，能持续为用户提供可靠的使用体验。

鸿蒙系统有着不少功能细节上的亮点。先说说小艺助手，它在升级后功能愈发强大且实用。现在小艺助手可以常驻屏幕底部，用户想要使用时能随手唤起，非常便捷。而且它还具备拖入文字、图片识别处理的功能，比如看到一张图片想知道上面的文字内容，直接拖入小艺助手就能快速识别并提供相关信息，方便用户进行下一步操作。

在主题个性化方面，更是增添了许多趣味功能。例如空气投篮主题，让用户在操作手机时仿佛在进行投篮游戏，趣味性十足。还有主题画廊点击预览功能，用户可以轻松浏览不同的主题样式，快速找到自己心仪的主题进行切换，能更好地满足大家对手机界面个性化的需求，展现出独特的功能优势，使手机使用起来更具趣味性和新鲜感。

当然，鸿蒙系统目前也还存在一些小问题。在部分软件功能上，还存在不够完善的地方，像一些第三方应用的适配还不够完美，以微信鸿蒙原生版为例，目前还处在测试阶段，功能相对安卓、iOS 版本有所阉割，只支持单聊、群聊、音视频通话等基础功能，像共享定位、语音输入、发红包、拍一拍等常用功能却暂未支持，给用户带来了一定的不便。

此外，在生态环境方面，鸿蒙系统虽然一直在积极拓展，接入的应用和服务也越来越多，但整体相比那些发展多年的成熟操作系统，仍有待进一步加强。例如专属应用数量目前相对有限，部分开发者对鸿蒙系统的适配积极性还不够高，一定程度上影响了用户能获取到的应用丰富度，这也是鸿蒙系统后续需要着重发力去改善的地方，不过相信随着时间推移，这些短板都会慢慢补齐。

鸿蒙系统采用的微内核架构有着诸多突出优势。首先是高安全性，与安卓系统采用的宏内核不同，宏内核把诸如文件系统、设备驱动、虚拟内存管理、网络协议栈等所有系统服务都放到内核里，像 linux2.6 内核代码量就超过 1100 万行，代码量庞大导致潜在漏洞防不胜防。而鸿蒙系统的微内核进行了功能简化，内核只提供如多进程调度、多进程通信（IPC）等最基础的系统服务，其他系统服务都放在内核之外的用户态来实现，有的微内核仅有 1 万行代码，还能够实现形式化证明，从数学上论证代码的安全性。

在高可靠性方面，微内核的内核非常稳定，众多系统服务运行在用户态模块上，并不会影响到系统整体的稳定性。

高扩展性也是一大亮点，由于众多系统服务都转移到了用户态服务模块上，那么就可以方便地根据终端的不同需求进行按需剪裁和添加，例如面对硬件规格差异极大的物联网终端时，能更好地适配，这一点宏内核由于所有服务都在内核中，要适应不同硬件就需要修改许多系统服务，适配性较差。

同时具备高可维护性，用户态模块可以彼此独立地进行启停、卸载和升级，操作起来更加灵活便捷。

此外，微内核还天然支持分布式计算，其用户态服务模块都是独立运行的，这为鸿蒙系统实现跨设备的互联互通等分布式应用场景提供了有力的底层支撑，让鸿蒙系统在多设备协同等方面能够大展身手。

方舟编译器对于提升安卓系统编写的 Java 代码运行效率有着重要作用。大家都知道，当前 Android 平台的绝大多数应用是使用 Java 语言编写的，而 CPU 只能理解汇编指令，所以通常需要一个包含翻译器和编译器的虚拟机（Virtual Machine，简称 VM），把 Java 高级语言转换成机器能懂的语言，但 VM 的存在往往会导致程序运行变慢甚至卡顿，像其统一回收内存垃圾时也会带来卡顿情况。

而华为方舟编译器最大的优势就在于绕过了 VM，它是将编译过程提前到应用开发阶段，通过方舟编译器开发的 APP，打包之后就直接以 0、1 这样的机器码存在，安装到手机中后，机器可以直接执行，不存在翻译过程，无需再经过 VM 的编译，从而大幅度减少了智能手机和操作系统的运行负担，使得应用在手机上能够快速安装、启动和运行。

例如，EMUI 9.1 仅仅对系统组件 System Serer 应用了华为方舟编译器后，系统操作流畅度提升 24%，系统响应性能提升 44%，第三方应用 “新浪微博极度版” 利用华为方舟编译器之后，操作流畅度更是提升了 60%，由此可见其对运行效率提升的显著效果。

鸿蒙系统在多设备协同方面的表现堪称出色，为用户打造了便捷智能的生活场景。就拿手机与平板、电视、汽车等不同设备之间的互联来说，实现了无缝切换、文件共享、任务接续等实用功能。

例如在文件共享方面，像鸿蒙 HarmonyOS NEXT 系统中的 “华为分享” 功能，用户可以轻松选择多达数台接收设备，并同时发送文件，打破了传统一对一的分享模式，实现更高效的家庭共享与团队协作。发送方只需简单操作选择待分享文件、点击分享按钮、挑选接收设备即可完成分享，接收方在控制中心点击 “华为分享” 就能轻松接收文件。而且还有 “所有人可见（10 分钟）” 和 “仅分享过的设备可见” 两种安全模式可灵活选择，兼顾分享的便捷性与私密性。

在任务接续上，以华为笔记本和华为手机的协同为例，通过 “超级终端” 一拉即合实现多屏协同后，能直接在 PC 端操作手机，手机甚至还化身为笔记本的 “无线 U 盘”，可以直接在笔记本上看到手机的文件盘符，方便进行文件的共享，比如将手机上的图片直接拖拽到电脑正在编辑的 PPT 文档中，无需数据线或繁琐的上传下载操作，大大提升了办公效率。

再比如和汽车的互联，当手机与汽车连接后，上车可以接续手机端的音乐播放、导航等任务，实现便捷的车机交互体验，让用户在不同设备间切换使用时毫无阻碍，充分展现了鸿蒙系统多设备协同的强大魅力，真正融入到了用户生活、办公等多场景之中。

目前，鸿蒙系统在应用适配方面已经取得了一定成果，但仍处于不断完善的过程中。像微信、支付宝、抖音、淘宝等国民级应用均已上线鸿蒙版，用户在日常使用这些常用软件时基本能保证便捷性，这得益于华为积极与开发者合作，提供完善的 SDK 与开发工具，解决兼容性难题，并且通过 “Ark 编译器” 等创新技术，实现了部分复杂应用的性能优化与高效运行，确保用户体验无损过渡。

不过，也还存在一些情况，部分应用的适配仍未达到尽善尽美的程度。例如微信鸿蒙原生版目前仅处于测试阶段，只支持单聊、群聊、音视频通话等基础社交功能，群接龙、群红包等常用功能暂无法使用；还有一些企业定制应用也存在适配缺乏的问题。而且从应用数量来看，虽然已经有超 1 万个应用和元服务成功上架 HarmonyOS NEXT 应用市场，可满足用户 99.9% 的使用时长，但和安卓的 Google Play 超 300 万个应用、苹果的 App Store 近 200 万个应用相比，数量差距仍较大。这在一定程度上限制了用户的应用丰富度选择，对整体使用体验有一些影响，不过随着时间推移，相信会有越来越多的应用完成适配工作。

展望未来，鸿蒙系统在生态建设方面有着广阔的发展前景和诸多发力方向。一方面，华为已经发布了鸿蒙原生应用开发者激励计划，旨在吸引更多开发者积极参与鸿蒙生态的建设，只要在计划要求时间提交报名且在 2024 年 10 月 10 日至 2024 年 12 月 31 日完成鸿蒙原生应用开发，上架至 HarmonyOS NEXT 应用市场，且满足评选标准就有机会获得现金及流量扶持的专属激励资源，最高可获百万现金和价值 500 万流量激励，这无疑会激发开发者们的创作热情，吸引更多的创新性应用加入生态。

同时，华为也在积极与众多厂商展开合作，例如润和软件旗下的润开鸿与蚂蚁数科举行战略合作签约仪式，发布基于鸿蒙的 mPaaS 移动应用开发产品，重点推动金融等垂直行业基于多端适配鸿蒙的应用开发项目及生态建设。后续相信会有更多不同领域的厂商参与进来，共同拓展鸿蒙系统的应用生态，使其覆盖更多行业和场景。

此外，结合当下快速发展的 AI 技术，鸿蒙生态对于 AI 应用的支持也在不断增强，例如在智能家居、车联网等领域的拓展应用，借助 AI 的能力为用户打造更智能、便捷的使用体验。随着越来越多的开发者和厂商综合运用华为鸿蒙系统的生态资源，整个市场有望迎来一个新的发展阶段，新的创新型应用会层出不穷，用户也能在更丰富的选择中找到更适合自己的产品，鸿蒙系统的生态环境也会愈发完善和繁荣。

总的来说，华为手机鸿蒙系统在目前的测评中展现出了诸多亮点，同时也存在一些有待提升之处。

从流畅度、稳定性以及功能细节亮点等使用感受方面来看，它在日常使用和运行大型游戏时都能有出色的流畅度表现，资源调度合理高效，切换任务顺滑；稳定性上，正常操作及高强度测试后都能较好维持运行，发热控制也在合理范围；功能细节更是增添了如小艺助手、趣味主题等实用又有趣的亮点。不过，像微信鸿蒙原生版等部分软件适配还不完善，生态应用数量相比成熟操作系统仍有差距等问题也客观存在。

在系统特色层面，微内核架构带来了高安全性、高可靠性、高扩展性和高可维护性等优势，方舟编译器对提升应用运行效率作用显著，多设备协同更是打造了便捷智能的生活与办公场景，实现了跨设备的无缝切换、文件共享、任务接续等实用功能。

而在生态环境建设上，尽管已经有众多国民级应用上线鸿蒙版，但整体应用数量和功能完善程度还有进步空间。不过，华为已经通过发布开发者激励计划、与众多厂商合作以及结合 AI 技术等方式积极推动生态的完善与拓展，未来前景广阔。

虽然鸿蒙系统目前还有可提升的空间，但凭借其现有的优势以及不断发展的态势，它未来的潜力巨大，值得广大用户继续关注和期待，相信随着时间的推移和技术的持续迭代，鸿蒙系统将会给我们带来更多的惊喜，在操作系统领域。

如何使用SpringSecurityOAuth2.0进行实战认证、资源服务自定义

文章都是成体系的，陈某默认看到这篇文章的读者都已经看了前期的文章，之前的知识点就不再详细介绍了。

今天这篇文章主要介绍一下实际工作中使用Spring Security需要定制的一些异常信息。

文章目录如下：

此篇文章沿用上篇文章的认证、资源服务，如下：

先来看一下正确的获取令牌的请求，以及 密码模式 为例，如下图：

密码模式需要传递 5 个参数，分别是 用户名 、 密码 、 客户端id ， 客户端秘钥 、 授权类型 。

故意输错用户名或者密码，返回信息如下：

输入一个不存在的授权类型，返回信息如下：

输入错误的客户端id或者秘钥，返回信息如下：

上面列举了三种常见的异常，解决方案实际可以分为两种：

• 用户名，密码错误异常、授权类型异常
• 客户端ID、秘钥异常

针对用户名、密码、授权类型错误的异常解决方式比较复杂，需要定制得比较多。

这部分根据自己业务需要定制，陈某这里只是给出个例子，代码如下：

需要自定义一个异常翻译器，默认的是 DefaultWebResponseExceptionTranslator ，此处必须重写，其中有一个需要实现的方法，如下：

这个方法就是根据传递过来的 Exception 判断不同的异常返回特定的信息，这里需要判断的异常的如下：

• UnsupportedGrantTypeException ：不支持的授权类型异常多
• InvalidGrantException ：用户名或者密码错误的异常

创建一个 OAuthServerWebResponseExceptionTranslator 实现 WebResponseExceptionTranslator ，代码如下：

需要将自定义的异常翻译器 OAuthServerWebResponseExceptionTranslator 在配置文件中配置，很简单，一行代码的事。

在 AuthorizationServerConfig 配置文件指定，代码如下：

按照上述的配置完成后，测试下用户名、密码错误、授权类型错误是否能够正确返回定制的提示信息，如下：

实践有了，总该理解一下为什么这么做吧？下面从源码的角度告诉你为什么要这么做？

我们知道获取令牌的接口为 /oauth/token ，这个接口定义在 TokenEndpoint#postAccessToken() （POST请求）方法中，如下图：

一般都是通过 @ExceptionHandler 特定的异常，然后统一地进行异常处理，是不是这样？

然后看一下上述的两种异常属于什么类型的，如下：

是不是都继承了 OAuth2Exception ，那么尝试在 TokenEndpoint 这个类中找找有没有处理 OAuth2Exception 这个异常强大的处理器，果然找到了一个 handleException() 方法，如下：

可以看到，这里的异常翻译器已经使用了我们自定义的 OAuthServerWebResponseExceptionTranslator 。可以看下默认的异常翻译器是啥，代码如下：

看到没，就是这个样子 DefaultWebResponseExceptionTranslator

问题又来了： 为什么在配置文件中设置了OAuthServerWebResponseExceptionTranslator就会生效呢？

这个不得不看下 @EnableAuthorizationServer 这个注解了，源码如下：

注入了这个 AuthorizationServerEndpointsConfiguration 配置类，其中注入了 AuthorizationEndpoint 这个bean，如下：

将自定义的异常翻译器设置进入了 AbstractEndpoint 这个抽象类中，而 TokenEndpoint 正是继承了这个抽象类，复用了其中的异常翻译器，代码如下：

哦对了，问题解决了，学东西一定要知其所以然……………

这部分比较复杂，想要理解还是需要些基础的，解决这个异常的方案很多，陈某只是介绍其中一种，下面详细介绍。

这部分根据自己业务需要定制，陈某这里只是给出个例子，代码如下：

这个 AuthenticationEntryPoint 是不是很熟悉，前面的文章已经介绍过了，此处需要自定义来返回定制的提示信息。

创建 OAuthServerAuthenticationEntryPoint ，实现AuthenticationEntryPoint，重写其中的方法，代码如下：

ClientCredentialsTokenEndpointFilter这个过滤器的主要作用就是校验客户端的ID、秘钥，代码如下：

有几个重要的部分需要讲一下，如下：

• 构造方法中需要传入第2步自定义的 OAuthServerAuthenticationEntryPoint
• 重写 getAuthenticationManager() 方法返回IOC中的AuthenticationManager
• 重写 afterPropertiesSet() 方法，用于自定义认证失败、成功处理器，失败处理器中调用 OAuthServerAuthenticationEntryPoint 进行异常提示信息返回

只需要将自定义的过滤器添加到 AuthorizationServerSecurityConfigurer 中，代码如下：

第 ① 部分是添加过滤器，其中 authenticationEntryPoint 使用的是第2步自定义的 OAuthServerAuthenticationEntryPoint

第 ② 部分一定要注意：一定要去掉这行代码，具体原因源码解释。

直接输入错误的秘钥，结果如下：

OAuthServerAuthenticationEntryPoint这个过滤器继承了 AbstractAuthenticationProcessingFilter 这个抽象类，一切的逻辑都在 doFilter() 中，陈某简化了其中的关键代码如下：

关键代码在 unsuccessfulAuthentication() 这个方法中，代码如下：

这个就要看 AuthorizationServerSecurityConfigurer#configure() 这个方法了，其中有一段代码如下：

这段代码就是遍历添加的过滤器将其添加到 过滤器链 中，在 BasicAuthenticationFilter 这个过滤器之前。

添加到security的过滤器链中，这个过滤器自然会生效了。

还是在 AuthorizationServerSecurityConfigurer#configure() 这个方法中，一旦设置了 allowFormAuthenticationForClients 为true，则会创建 ClientCredentialsTokenEndpointFilter ，此时自定义的自然失效了。

从认证服务获取到令牌之后去请求资源服务的资源，这里涉及到的异常主要有两个，如下：

比如令牌不正确、过期，此时返回的异常提示如下：

令牌的权限不足，比如 /admin 接口只允许 admin 角色访问，此时返回的异常信息如下：

下面针对上述两种异常分别定制异常提示信息，这个比认证服务定制简单。

这个比较简单，也是需要自定义 AuthenticationEntryPoint 。步骤如下：

这个和认证服务的客户端异常类似，这里不再详细说了，直接贴代码，如下：

这个比较简单，直接在配置文件中配置即可，代码如下：

此时拿着失效的令牌访问资源服务，可以看到已经正常返回定制的提示信息了，如下：

源码和认证服务的类似，自己断点试试，还是很简单的。

这个异常定制就更简单了，陈某在第一篇文章： 实战！Spring Boot Security+JWT前后端分离架构登录认证！ 介绍过，下面简单的贴下代码。

代码如下：

和令牌失效的异常配置在同一个方法中，代码如下：

访问 /admin 接口，此时的提示信息如下：

原文链接：https://www.tuicool.com/articles/aYB7nuf

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com