java面试看这一篇就够了

由于最近比较忙，项目赶的比较紧所以一直没有更新整理面试题，这次抽了些时间把答应大家的面试题整理出来了感谢各位小伙伴们的支持，你们的支持是我分享的动力，希望在以后的日子里咱们共同学习进步。如果感觉不错就多多分享、收藏、关注。篇幅有点长建议先收藏。

                                                                   Jason

springboot相关面试话术

1、什么是springboot

SpringBoot是Spring项目中的一个子工程，其实人们把Spring Boot 称为搭建程序的脚手架。其最主要作用就是帮我们快速的构建庞大的spring项目，并且尽可能的减少一切xml配置，做到开箱即用，迅速上手，让我们关注与业务而非配置。

2、为什么要用springboot

Spring Boot 优点非常多，如：一、独立运行Spring Boot而且内嵌了各种servlet容器，Tomcat、Jetty等，现在不再需要打成war包部署到容器中，Spring Boot只要打成一个可执行的jar包就能独立运行，所有的依赖包都在一个jar包内。二、简化配置spring-boot-starter-web启动器自动依赖其他组件，简少了maven的配置。三、自动配置Spring Boot能根据当前类路径下的类、jar包来自动配置bean，如添加一个spring-boot-starter-web启动器就能拥有web的功能，无需其他配置。四、无代码生成和XML配置Spring Boot配置过程中无代码生成，也无需XML配置文件就能完成所有配置工作，这一切都是借助于条件注解完成的，这也是Spring4.x的核心功能之一。五、应用监控Spring Boot提供一系列端点可以监控服务及应用，做健康检测

3、springboot有哪些优点

减少开发，测试时间和努力。使用 JavaCong 有助于避免使用 XML。避免大量的 Maven 导入和各种版本冲突。通过提供默认值快速开始开发。没有单独的 Web 服务器需要。这意味着你不再需要启动 Tomcat，Glasssh或其他任何东西。需要更少的配置 因为没有 web.xml 文件。只需添加用@ Conguration 注释的类，然后添加用@Bean 注释的方法，Spring 将自动加载对象并像以前一样对其进行管理。您甚至可以将@Autowired 添加到 bean 方法中，以使 Spring 自动装入需要的依赖关系中。基于环境的配置 使用这些属性，您可以将您正在使用的环境传递到应用程序：-Dspring.proles.active = {enviornment}。在加载主应用程序属性文件后，Spring 将在（application{environment} .properties）中加载后续的应用程序属性文件。application.yml

spring.active.profile=dev

application-dev.yml

application-test.yml

application-prod.yml

4、Spring Boot 的核心注解是哪个？它主要由哪几个注解组成的？

启动类上面的注解是@SpringBootApplication，它也是 Spring Boot 的核心注解，主要组合包含了以下3 个注解：@SpringBootConguration：组合了 @Conguration 注解，实现配置文件的功能。@EnableAutoConguration：打开自动配置的功能，也可以关闭某个自动配置的选项，如关闭数据源自动配置功能：@SpringBootApplication(exclude = { DataSourceAutoConguration.class })。@ComponentScan：Spring组件扫描，从当前类所在的包以及子包扫描，之外的包扫描不到，所以我们在开发的时候，所有的类都在主类的子包下

5、springboot项目有哪几种运行方式

打包用命令或者放到容器中运行用 Maven/Gradle 插件运行直接执行 main 方法运行6、如何理解springboot中的starters？

Starters可以理解为启动器，它包含了一系列可以集成到应用里面的依赖包，你可以一站式集成Spring及其他技术，而不需要到处找示例代码和依赖包。如你想使用Spring JPA访问数据库，只要加入springboot-starter-data-jpa启动器依赖就能使用了。Starters包含了许多项目中需要用到的依赖，它们能快速持续的运行，都是一系列得到支持的管理传递性依赖。

7、springboot自动配置原理

这个就得从springboot项目的核心注解@SpringbootApplication说起了，这个注解包含了三个注解，其中一个是@EnableAutoConfiguration注解，这个注解主要是开启自动配置的，这个注解会"猜"你将如何配置 spring，前提是你已经添加 了 jar 依赖项，比如项目中引入了 spring-boot-starter-web ，这个包里已经添加 Tomcat 和 SpringMVC，这个注解节就会自动假设您在开发一个 web 应用程序并添加相应的 spring 配置，springboot默认有一个spring-boot-autoconfigure包，大多数常用的第三方的配置都自动集成了，像redis、es等，这里边有一个META-INF/spring.factories文件，这里边定义了所有需要加载的bean的全路径，spring会根据反射的原理，创建这些对象，放到IOC容器中，加载时需要的参数，通过JavaConfig的方式加载配置文件中的参数然后创建了对应的对象，这就是自动配置的原理

2

springcloud相关面试话术

1、什么是Springcloud

Spring Cloud 是一系列框架的集合，它利用 Spring Boot 的开发便利性简化 了分布式系统的开发，比如服务发现、服务网关、服务路由、链路追踪等。他的设计目的是为 了简化 Spring 应用的搭建和开发过程。该框架遵循“约定大于配置”原则，采用特定的方 式进行配置，从而使开发者不用定义大量的 XML 配置。Spring Cloud 并不重复造轮子，而是将市 面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。核心组件:Eureka、Ribbon、Feign、 Hystrix、Zuul.

为什么要使用这个呢？因为之前的嗯项目架构都是集中式的。这就会导致一个问题在项目当中出现任何一个小问题都会让整个项目不能使用。修改完之后需要让整个项目全量更新，所以基于传统架构的这种方式，我们在这个项目当中把，架构调整了一下，采用了微服务的架构。那使用了微服务架构之后，在整体的分配任务上呀，还有扩展性上来讲，比以前的开发以及这个效率上都有很显著的提高。

我介绍一下spring cloud里边儿的一些组件吧，我们项目当中使用的。首先就是它的注册中心Eureka。所有的微服务。都需要连接Eureka去进行管理。它里边儿会有心跳协议，会知道每个微服务具体的一个在线状态。以及给其他调用微服务的这些去提供一些这这个微服务的基本信息

接着就是这个远程调用feign，它提供了微服务之间的远程调用的一个组件，它是基于HTTP的。然后，远程调用这个组件集成了负载均衡ribbon。它可以有效的分辨出当前注册中心当中这个为服务有多少实例，会根据内部的算法去均衡的域访问这些实例，它的算法有轮询还有随机，这个算法我们也可以自定义，它默认的算法呢是轮循去访问

接着就是。熔断器hystrix。那他这个组件儿在我们项目当中用的时候，就是在远程调用时。如果任何一个微服务响应超时或者发生异常，熔断器就会介入，把当前请求切断。然后去执行我们的回调方法，返回回调方法当中的数据。这样的话会保证我们微服务当中的请求链路不会卡死，而且，这样的话不会让用户在前台一直在等着。会有一个非常好的用户体验。

接着就是我们的网关。Zuul。网关在我们项目当中充当的地位就是一个所有请求的入口。所有请求进来之后，首先通过网关有网关，根据路径儿去解析，然后转发到对应的微服务上，当然这个网关还充当了一个功能，就是一个鉴权功能，我们项目当中，登陆了之后，会给用户颁发一个token。用户在访问的时候，这个token会携带在请求头当中，经过我们网关时，网关会拦截取出token。验证token的真实性。验证通过之后才会访问到我们的微服务。这就是我们项目当中微服务具体使用的一些场景以及它的组件。

2、服务注册和服务发现是什么意思，springcloud是如何实现的

在微服务项目中，我们通常会用到服务之间的相互调用，我们通常在属性文件中进行所有的需要请求的微服务的地址端口等信息。随着越来越多的 服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下架，而某些位置可 能会发生变化。手动更改属性可能会产生问题。Eureka 提供了服务注册和服务发现的功能，服务注册是让所有微服务将自己的信息注册到注册中心，服务发现是让微服务可以拉取注册中心里的服务列表，方便结合feign进行远程调用，由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找， 因此无需处理服务地点的任何更改和处理。

3、负载均衡的意义是什么

我觉得负载均衡的主要意义就是，避免单一应用由于并发等原因，导致应用宕机从而导致系统整体无法使用，多负载同时工作，可以很好的解决高并发的问题，实现服务的高可用。

在我们项目中，服务的接入层由nginx管理，用户请求经过nginx之后，根据相应的域名，转发到对应的服务器去，由于nginx只负责请求转发，没有业务逻辑处理，所以效率上非常高。

nginx支持的负载均衡策略有很多，我们在nginx.conf中配置upstream模块即可。

首先是轮训，默认的就是这种方式

第二种权重的方式，就是根据服务器的性能，配置较大的权重，nginx就会分配更多的请求

第三种是iphash的方式，nginx会根据请求的ip地址，今夕那个hash运算，然后分配相应的服务器，后续来自同一ip的请求都会分配到这个服务器上

第四种是最少连接数，把请求转发给连接数较少的后端服务器

还有就是可以根据响应时间和url hash来做处理，我们项目中配置的是权重的方式。

在我们项目的微服务架构中，feign和zuul都集成了ribbon的的功能，它是负责在微服务之间相互调用的时候，帮我们实现负载均衡的功能，我们在将微服务注册到注册中心时，如果服务名称一致，就默认为一个集群，在进行远程调用或者路由转发的时候，都可以均衡的访问响应的服务器，ribbon的负载均衡机制有轮训和随机，默认是轮训，当然也可以自定义负载均衡的策略。

4、hystrix介绍

hystrix在微服务架构中充当熔断器的功能，它提供了资源隔离、限流、熔断、降级、运维监控等功能，

在微服务架构中通常会有多个微服务之间相互调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，直接执行回调方法，返回回调方法中的友好数据或者缓存数据，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经、修正，应用程序会再次尝试调用操作。

当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%)，断路器会切换到开路状态(Open)。这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况，如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix 的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。

5、Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别

1、ZooKeeper保证的是CP，就是一致性和容错，Eureka保证的是AP，就是可用性和容错。

ZooKeeper在选举期间注册服务瘫痪，虽然服务最终会恢复，但是选举期间不可用的，只有等到选举结束之后，所有数据同步之后才能使用。

Eureka各个节点是平等关系，只要有一台Eureka就可以保证服务可用，而查询到的数据并不是最新的，自我保护机制会导致Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务。Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点(高可用)，当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像ZooKeeper一样使得整个注册系统瘫痪

2、ZooKeeper有Leader和Follower角色，Eureka各个节点平等

3、ZooKeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题

4、Eureka本质上是一个微服务的一个模块，而ZooKeeper是一个进程，需要单独安装

3

ElasticSearch相关面试话术

1、介绍一下ElasticSearch，以及在项目中的应用

Java开发的基于lucene分布式全文搜索引擎。基于restful Web接口。在检索领域相当优秀，在我们项目中主要是负责检索商品信息。商品信息构成是比较复杂的，并且数据量巨大，至少会有几十万，如果使用mysql做检索，效率会非常低，并且对mysql造成很大的压力。

在使用过程中主要需要做几件事：

1、Es服务的安装，中文分词器使用IK分词器，这个主要是运维负责；

2、在项目中集成springDataElasticSearch框架，用来操作ES；

3、创建实体类，标注了一个Document注解，这个注解里声明了这个索引库的名称以及它的类型，还有他的分片儿信息，还有他的副本信息。在这个类中创建所有跟商品相关的字段。同样会有一些注解去标识他的数据类型，他的比如说id字段会有一个id注解，其他字段用@Field注解标注在es中存储的数据类型，是否进行分词等，有些字段也可以不加任何注解，es会根据存储的数据去判断字段在es中存储的类型。等其他的字段都建好之后，然后又新添加了一个统一的搜索字段，我们给它定义的名称叫all，我们会把经常搜索的数据全部定义到这个字段里。比方说商品标题、副标题、品牌等；

4、初始全量数据导入

使用springboot测试类实现导入，分批从mysql中取出，组装数据到，保存到es中

5、修改、新增、删除等增量数据导入

使用rabbitMQ实现，商品上下架的时候发送Mq消息，搜索微服务以及静态页面微服务实现ES数据的同步和静态页面的数据同步操作

6、使用es实现搜索

使用all进行分词查询，搜索时，按照matchQuery做的，这个方法的做法是会把输入的关键词分词之后，然后去匹配，匹配的规则我们设置的是and的方式匹配，就是分词之后每个词条都匹配才算匹配，我们在项目里设置了个all字段，会把所有可能被分词的字段都会放到这个里边，只对这一个字段设置分词，关键字搜索的时候，都会去匹配这个字段，使用规格参数聚合实现商品搜索规格参数的渲染使用分类和品牌聚合实现商品分类和品牌查询的渲染使用布尔查询实现规格参数、品牌、分类的过滤实现分页、排序等需求2、为什么使用Es？

因为在我们商城中的数据，将来会非常多，所以采用以往的模糊查询，模糊查询前置配置，会放弃索引，导致商品查询是全表扫面，在百万级别的数据库中，效率非常低下，而我们使用ES做一个全文索引，我们将经常查询的商品的某些字段，比如说商品名，描述、价格还有id这些字段我们放入我们索引库里，es内部有个倒排索引的机制，普通的索引的原理是通过id寻找数据，而倒排索引是通过数据寻找id，它的大概原理是把需要分词的数据通过ik分词器分词之后，记录出每个词条对应的文档id，在进行搜索的时候，将搜索关键字分词之后，找到每个词条的文档id，然后在进行通过id搜索操作，大大提高了全文检索的效率，这也是在全文检索方面最常用的技术。

3、 什么是桶（bucket）？什么是度量（metrics）？

桶，是按照某种方式对数据进行分组，每一组数据在ES中称为一个桶，例如我们根据国籍对人划分，可以得到中国桶、英国桶，日本桶……或者我们按照年龄段对人进行划分：010,1020,2030,3040等。分桶的方式有很多，比如按日期阶梯分组、按数值阶梯分组、按词条内容分组、按数值和日期范围分组等。

度量，分组完成以后，我们一般会对组中的数据进行聚合运算，例如求平均值、最大、最小、求和等，这些在ES中称为度量。度量有求平均值、求最大最小值、求百分比、求和等。

4、es内部存储的存储结构

es内部默认就是分布式的存储结构，每当创建一个索引库的时候，我们需要指定当前索引库的分片数和副本数，分片数就是把数据分布式的存放在分片上，所有分片的数据加起来就是整个索引库的数据量，分片数越多，数据存放的越分散，搜索的时候，es会检索每个分片的伤的数据一起返回。副本数是指在数据进入索引库的时候，同时需要备份的数量，如果副本数量越多，那么需要消耗的存储空间就会越多，过多的话会造成空间浪费，一般生产中使用的时候都用的默认的配置，就是5个分片，2个副本。

4

页面静态化相关面试话术

首先说说为什么要进行页面静态化

从搜索这里可以看出，搜索列表展示的是固定30条数据，搜索的访问量已经很巨大了，那么详情页面的访问量是30倍的搜索量，如果放在整个百万级的用户量上来说，这个访问量是很巨大的，所以我们就不能每次访问详情页面的时候，都去服务端请求数据再展示

其次是这个详情页面来说，不会经常频繁的变动，所以每次去服务端取的数据基本都是一致的，所以我们就得想办法去解决如何快速的响应这么高的访问量

我们项目中服务端的请求和前端的请求，都是通过nginx做的反向代理，那么我们在项目中的方案是基于两个点去解决的，首先呢是结合模版引擎技术，用户在首次访问某个数据的详情页的时候，我们使用thymeleaf给生成静态页面，响应给用户，同时放到指定的nginx代理的目录下，那么用户在第二次访问这个数据详情页是，通过nginx中的配置，nginx首先会去该目录下查看是否有这个数据静态页面存在，如果存在的话，直接就访问静态html文件了，如果不存在，才会放行到我们微服务里去请求数据。

然后在线上的时候，会结合CDN技术，同时指向nginx代理的静态页面的路径，进一步提高用户的访问速度。

在生成静态页面的同时会造成一个问题，就是数据库的数据修改之后，需要同步到静态页面中去，这里我们采用的是rabbitmq做的异步处理，在数据库数据修改之后，通过mq发送消息，静态化的微服务收到消息之后，会重新生成一遍html页面，这样就会跟数据库的数据同步了

5

rabbitmq相关面试话术

1、介绍一下rabbitmq

RabbitMQ是Erlang语言开发的基于AMQP的一款消息中间件，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先发送给交换机，然后由交换机转发给对应的队列。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。

它里边有5种数据传递方式

第一种是简单模型，一个生产者，一个队列，一个消费者，队列只能被一个消费者监听，所以生产者将消息发给队列之后，只能有一个消费者收到消息

第二种是工作模型，一个生产者，一个队列，多个消费者，队列可以被多个消费者监听，但是生产者将消息发给队列之后，还是只能有一个消费者接收到消息

后边三种都叫订阅模型，这三种里边引入了交换机的概念，具体的区分是根据交换机的类型区分的，在这三种模式种，生产者把消息发送给交换机，交换机不负责存储消息，由交换机发送给指定的队列，消费者监听队列消费消息。

首先是fanout类型，这种叫广播模式，生产者将消息发送给交换机，交换机会将消息转发给所有绑定到到当前交换机的队列中，对应监听队列的消费者都能收到消息，但是，如果没有队列绑定到这个交换机，消息会被mq丢弃。

接着是direct类型，这种叫定向模式，也叫路由模式，这种模式中，队列在绑定交换机的时候，同时指定了自己的routing key，可以理解为一个路由标示，生产者在发送消息给交换机的时候，同时指定要发送给的routing key，这时候，交换机就会根据这个routing key来定向的发送给对应的队列，对应监听该routing key的队列的消费者就能收到消息，但是如果交换机没有找到对应的routing key，消息会被丢弃。

最后是topic模式，这种叫通配符模式，队列在绑定交换机的时候，同时指定了自己的routing key，生产者在发送消息给交换机的时候，同时指定要发送给的routing key 的通配符，一般这个routing key是由多个单词用.的方式隔开的，通配符中，#号可以匹配一个或者多个单词，*号只能匹配一个单词，例如生产者指定的通配符为a.#，可以匹配到的routing key有：a.b、a.b.c等，如果是a.*的话，只能匹配a.b或者是a.c这样的routing key。每个队列绑定到交换机的时候可以定义多个routing key，交换机会跟据指定的通配符，发送到匹配通配符的routing key 对应的队列中，对应的消费者就可以收到消息了，但是，如果没有符合通配符的routing key ，消息会被丢弃

当然，在生产中使用的时候，为了避免mq宕掉等造成消息丢失的问题，我们都会配置持久化措施，在rabbitmq里，需要将交换机持和队列和消息持久化，这样消息就会被持久化到磁盘中，不会因为突发的断电等情况导致消息丢失

2、如何保证消息确定消息发送成功，并且被消费成功，有什么保障措施

解析：这里不用背，这里的问法会有很多中，这道题中问了两部分第一部分是确保发送成功，还可以被问成：消息发送失败了怎么办，或者如何保证消息可靠传输第二部分是确保消费成功，还可以被问成：消息消费时，发生异常了，消息已经被消费了，怎么办等

首先，需要确保消息被发送成功，rabbitmq中提供了事物和confirm的机制，事物的话，就类似于数据库的事物，开启，执行，提交，如果过程中发生任何异常，就会触发回滚机制，我们可以在回滚中加入一些逻辑处理，重新发送或者日志记录，同时配置生产者确认的机制，就是在消息发送之后，该消息会被指定唯一的ID，如果有消息成功被交换机转发到队列之后，mq会给生产者发送ack确认，如果没有队列接收消息，那么会发送错误回执消息给生产者，生产者可以尝试重试发送，或者日志记录。通过这些可以看出，mq会增加一些保障性措施，必然会导致性能有一些下降，如果要保证消息的严格一致性，那么可以配置这些，如果消息不重要，或者允许有丢失的情况，那么可以不用配置，这样的话能提升mq的性能。

其次就是，消息确保发送成功之后，还要确保消息被消费成功，因为在消费者端，如果消息消费时发生异常，又没有做一些处理，那么消息就会丢失，这种情况，可以采取两种方式解决

第一种就是消费端配置手动ACK确认机制，消息被消费完成的时候，手动确认告诉mq消费成功，mq才会删除消息，如果消息被接收了，但是mq没有收到ack确认，那么消息在mq中会变为unacked状态，我们可以通过项目日志或者mq面板监控，当消费者断开连接之后，消息会重新回到队列中，消费者重新连接之后，会再次收到消息。

第二种就是可以结合数据库解决，生产者端发送成功之后，可以在数据库中存储发送的消息和发送时间，并标记状态为未消费状态，消费者端消费完成之后，标记mysql中数据的状态为已经消费。消费者端通过定时任务去数据库跑批检索超时未被消费的消息并重新发送，这种方式可以很好的解决消费失败的问题，但是增加了生产者和消费者之间的耦合度，以及会造成消息重复消费的问题，我们可以在保证消息发送成功的基础上，将上述逻辑放在消费者端，生产者正常发送消息，消费者在收到消息之后，存储到myqsl中，标记状态为未消费，同时ack通知mq确认，然后再消费消息，消息消费成功之后，改变mysql状态为已消费，消费端同时配置定时任务跑批检索数据库，定时重新执行超时未消费的消息。

以上的解决办法都是需要根据实际的业务需求来的，如果消息需要保证强一致性，不能出现任何差错，那么就需要按照前面说的添加对应的配置

我们项目中的mq主要用于数据同步使用的，mysql数据发生变化之后，需要同步到es索引库以及静态化页面中，这里我们配置了生产者确认模式，和消费者手动ack确认机制。

3、如何保证消息不被重复消费

我们可以在生产者端，发送消息时，数据的变动部分，进行md5加密处理，同时配置上一个唯一id，每次发送的数据的唯一id是递增的，相当于版本号的功能，在消费者端，收到消息之后，首先去数据库匹配一下md5值如果数据库中记录的当前记录已经被消费，那么就不进行消费，如果发现数据库没有记录当前消息，或者记录的状态没有被消费，那么才会重新消费该消息

4、RabbitMQ 宕机了怎么处理

RabbitMQ 提供了持久化的机制，将内存中的消息持久化到硬盘上，即使重启 RabbitMQ，消息也不会丢失。持久化队列和非持久化队列的区别是，持久化队列会被保存在磁盘中，固定并持久的存储，当 Rabbit 服务重启后，该队列会保持原来的状态在RabbitMQ 中被管理，而非持久化队列不会被保存在磁盘中，Rabbit 服务重启后队列就会消失。非持久化比持久化的优势就是，由于非持久化不需要保存在磁盘中，所以使用速度就比持久化队列快。即是非持久化的性能要高于持久化。而持久化的优点就是消息会一直存在，不会随服务的重启或服务器的宕机而消失。使用的时候需要根据实际需求来判断具体如何使用。

6

认证授权相关面试话术

1、你给我说一下授权认证（登陆注册）的逻辑

这块来说就比较简单了，我们提供的注册功能有用户名密码注册，手机号注册，微信登陆绑定注册功能

用户名密码注册登陆我们系统规定的是用户名不得重复，注册的时候，会去做一下重复校验，向后台提交注册信息的时候，密码都会经过md5加密传输&#x