马斯洛的需求层次结构是心理学中的激励理论，通常指的是人类需求的五级模型。 mermaid graph TD 马斯洛需求层析理论 - 生理需求 马斯洛需求层析理论 - 安全需求 马斯洛需求层析理论 - 社交需求-归属与爱系或关系 马斯洛需求层析理论 - 尊重需求 马斯洛需求层析理论 - 自我实现需求 在后来五阶段模型已经扩大为八阶，包括认知和审美需求和后来的超越需求： 生理的需要（physiological need） 食物、水分、空气、睡眠、性的需要等。它们在人的需要中最重要，最有力量。 安全需要（safety need） 人们需要稳定、安全、受到保护、有秩序、能免除恐惧和焦虑等。 归属和爱的需要（belongingness and love need） 一个人要求与其他人建立感情的联系或关系。例子：结交朋友、追求爱情。 尊重的需要（esteem need） 马斯洛分为两类：（一） 尊重自己（尊严、成就、掌握、独立）和（二） 对他人的名誉或尊重（例如地位、威望）。 认知需求（Cognitive needs） 知识和理解、好奇心、探索、意义和可预测性需求。 审美需求（Aesthetic needs） 欣赏和寻找美，平衡，形式等。 自我实现的需要（self -actualization need） 人们追求实现自己的能力或者潜能，并使之完善化。 超越需要（Transcendence needs） 一个人的动机是超越个人自我的价值观 人在每个时期，都会有一种需求占主导地位，而其他需求处于从属地位，我们在分析用户需求和痛点时就可以结合这个理论进行分析。

之前通过[Spring Boot 2.x基础教程：使用Swagger2构建强大的API文档](http://blog.didispace.com/spring-boot-learning-21-2-2/)一文，我们学习了如何使用Swagger为Spring Boot项目自动生成API文档，有不少用户留言问了关于文档内容的组织以及排序问题。所以，就特别开一篇详细说说Swagger中文档内容如何来组织以及其中各个元素如何控制前后顺序的具体配置方法。 接口的分组 我们在Spring Boot中定义各个接口是以 Controller 作为第一级维度来进行组织的， Controller 与具体接口之间的关系是一对多的关系。我们可以将同属一个模块的接口定义在一个 Controller 里。默认情况下，Swagger是以 Controller 为单位，对接口进行分组管理的。这个分组的元素在Swagger中称为 Tag ，但是这里的 Tag 与接口的关系并不是一对多的，它支持更丰富的多对多关系。 默认分组 首先，我们通过一个简单的例子，来看一下默认情况，Swagger是如何根据 Controller 来组织Tag与接口关系的。定义两个 Controller ，分别负责教师管理与学生管理接口，比如下面这样： java @RestController @RequestMapping(value = "/teacher") static class TeacherController { @GetMapping("/xxx") public String xxx() { return "xxx"; } } @RestController @RequestMapping(value = "/student") static class StudentController { @ApiOperation("获取学生清单") @GetMapping("/list") public String bbb() { return "bbb"; } @ApiOperation("获取教某个学生的老师清单") @GetMapping("/his-teachers")

请求参数的校验是很多新手开发非常容易犯错，或存在较多改进点的常见场景。比较常见的问题主要表现在以下几个方面： 仅依靠前端框架解决参数校验，缺失服务端的校验。这种情况常见于需要同时开发前后端的时候，虽然程序的正常使用不会有问题，但是开发者忽略了非正常操作。比如绕过前端程序，直接模拟客户端请求，这时候就会突然在前端预设的各种限制，直击各种数据访问接口，使得我们的系统存在安全隐患。 大量地使用 if/else 语句嵌套实现，校验逻辑晦涩难通，不利于长期维护。 所以，针对上面的问题，建议服务端开发在实现接口的时候，对于请求参数必须要有服务端校验以保障数据安全与稳定的系统运行。同时，对于参数的校验实现需要足够优雅，要满足逻辑易读、易维护的基本特点。 接下来，我们就在本篇教程中详细说说，如何优雅地实现Spring Boot服务端的请求参数校验。 JSR-303 在开始动手实践之前，我们先了解一下接下来我们将使用的一项标准规范：JSR-303 什么是JSR？ JSR是Java Specification Requests的缩写，意思是Java 规范提案。是指向JCP(Java Community Process)提出新增一个标准化技术规范的正式请求。任何人都可以提交JSR，以向Java平台增添新的API和服务。JSR已成为Java界的一个重要标准。 JSR-303定义的是什么标准？ JSR-303 是JAVA EE 6 中的一项子规范，叫做Bean Validation，Hibernate Validator 是 Bean Validation 的参考实现 . Hibernate Validator 提供了 JSR 303 规范中所有内置 constraint 的实现，除此之外还有一些附加的 constraint。 Bean Validation中内置的constraint Hibernate Validator附加的constraint ![59e11c6ec5c8417db8b231a443a72c33](ht

mermaid graph TD SWOT分析法 - Strengths-优势 SWOT分析法 - Weaknesses-劣势 SWOT分析法 - Opportunities-机会 SWOT分析法 - Threats-威胁 SWOT是由 优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）、威胁（Threats） 这四个英文字母首字母组合。 所谓SWOT分析，即 基于内外部竞争环境和竞争条件下的态势分析，就是将与研究对象密切相关的各种主要内部优势、劣势和外部的机会和威胁等，通过调查列举出来，并依照矩阵形式排列，然后用系统分析的思想，把各种因素相互匹配起来加以分析，从中得出一系列相应的结论，而结论通常带有一定的决策性 。 运用这种方法再结合PEST分析法，可以对研究对象所处的情景进行全面、系统、准确的研究，从而根据研究结果制定相应的发展战略、计划以及对策等。 我们在做竞品分析时可以利用SWOT分析法全面的思考竞争对手与自身的优劣势，更全面的制定或调整战略。

mermaid graph TD PEST分析法 - Politics-政治 PEST分析法 - Economic-经济 PEST分析法 - Society-社会 PEST分析法 - Technology-技术 PEST是 政治（Politics）、经济（Economic）、社会（Society）、技术（Technology） 这四个英文字母首字母组合。 PEST分析是指准对宏观环境的分析，应用场景， 基于公司战略的眼光来分析企业外部宏观环境 。公司战略制定是离不开宏观环境的。 政治（Politics），指的政治干预的程度，需要关注出台了什么政策、法律法规，对公司的经营是否有较大影响。 经济（Economic），企业在制定战略过程中需要考虑国内外经济条件、宏观政策、经济发展水平等多种因素，这些因素会影响产品的定价策略。 社会（Society），主要指社会成员的民族特征、文化传统、价值观念、教育水平、风俗习惯等，这些会影响公司产品用户的性别比例、地域分布、生活方式、购买习惯、受教育程度等。 技术（Technology），指企业所涉及国家地区的技术水平、技术政策、新产品开发能力和技术发展的动态，对于企业的主要影响就是技术的更新以及商业化速度和发展趋势，国家重点扶持项目等。

mermaid graph TD STAR原则 - Situation-情景 STAR原则 - Task-任务 STAR原则 - Action-行动 STAR原则 - Result-结果 STAR原则是： Situation（情景）、Task（任务）、Action（行动）和Result（结果 ）这四个英文字母首字母组合。 STAR原则在面试中应用最多，但是作为产品经理，STAR原则对于产品设计同样适用，可以通过STAR原则描述用户故事以及复盘工作。 在设计功能的时候，我们需要考虑，用户场景、功能目标、用户行为目标和产品效果。 用户场景：用户的类型和特特征、什么情况下用户会使用、用户为什么会使用 功能目标：这个产品解决了什么问题、问题的关键点是什么 行为路径：如何设计产品流程、如何提高用户的效率 产品效果：产品是否真正的解决了这个问题、效果是否达到了预期

这里的5W和2H是英文单词的缩写 5W的指的是： what — 是什么？做什么？目的是什么？ why — 为什么做？可以不可以不做？有没有替代方案？ who — 谁？由谁来做？ when — 什么时间做？ where — 在哪里做？ 2H how — 怎么做？如何实施？方法是什么？ how much — 多少？做到什么程度？数量如何？质量水平如何？费用产出如何？ 七问分析法可以帮我们梳理业务，当拿到一个需求时，我们可以围绕这七个问题去思考，检验这个需求是否合理，是否必须做。

随着前后端分离架构和微服务架构的流行，我们使用Spring Boot来构建RESTful API项目的场景越来越多。通常我们的一个RESTful API就有可能要服务于多个不同的开发人员或开发团队：IOS开发、Android开发、Web开发甚至其他的后端服务等。为了减少与其他团队平时开发期间的频繁沟通成本，传统做法就是创建一份RESTful API文档来记录所有接口细节，然而这样的做法有以下几个问题： 由于接口众多，并且细节复杂（需要考虑不同的HTTP请求类型、HTTP头部信息、HTTP请求内容等），高质量地创建这份文档本身就是件非常吃力的事，下游的抱怨声不绝于耳。 随着时间推移，不断修改接口实现的时候都必须同步修改接口文档，而文档与代码又处于两个不同的媒介，除非有严格的管理机制，不然很容易导致不一致现象。 为了解决上面这样的问题，本文将介绍RESTful API的重磅好伙伴Swagger2，它可以轻松的整合到Spring Boot中，并与Spring MVC程序配合组织出强大RESTful API文档。它既可以减少我们创建文档的工作量，同时说明内容又整合入实现代码中，让维护文档和修改代码整合为一体，可以让我们在修改代码逻辑的同时方便的修改文档说明。另外Swagger2也提供了强大的页面测试功能来调试每个RESTful API。具体效果如下图所示： 下面来具体介绍，在Spring Boot中使用我们自己实现的starter来整合Swagger。该整合项目的Github： https://github.com/SpringForAll/spring-boot-starter-swagger 。如果您觉得它好用，欢迎Star支持我们！ 准备工作 首先，我们需要一个Spring Boot实现的RESTful API工程，若您没有做过这类内容，建议先阅读上一篇教程： [Spring Boot 2.x基础教程：构建RESTful API与单元测试](http://blog.didispace.com/spring-boot-learning-21-2-1/

首先，回顾并详细说明一下在[快速入门](http://blog.didispace.com/spring-boot-learning-21-1-1/)中使用的 @Controller 、 @RestController 、 @RequestMapping 注解。如果您对Spring MVC不熟悉并且还没有尝试过快速入门案例，建议先看一下[快速入门](http://blog.didispace.com/spring-boot-learning-21-1-1/)的内容。 @Controller ：修饰class，用来创建处理http请求的对象 @RestController ：Spring4之后加入的注解，原来在 @Controller 中返回json需要 @ResponseBody 来配合，如果直接用 @RestController 替代 @Controller 就不需要再配置 @ResponseBody ，默认返回json格式 @RequestMapping ：配置url映射。现在更多的也会直接用以Http Method直接关联的映射注解来定义，比如： GetMapping 、 PostMapping 、 DeleteMapping 、 PutMapping 等 下面我们通过使用Spring MVC来实现一组对User对象操作的RESTful API，配合注释详细说明在Spring MVC中如何映射HTTP请求、如何传参、如何编写单元测试。 RESTful API具体设计如下： 定义User实体 java @Data public class User { private Long id; private String name; private Integer age; } 注意：相比[1.x版本教程](http://blog.didispace.com/springbootrestfulapi/)中自定义set和get函数的方式，这里使用 @Data 注解可以实现在编译器自动添加s

在之前的系列教程中，我们已经介绍了非常多关于Spring Boot配置文件中的各种细节用法，比如：[参数间的引用](http://blog.didispace.com/spring-boot-learning-21-1-3/)、[随机数的应用](http://blog.didispace.com/spring-boot-learning-21-1-3/)、[命令行参数的使用](http://blog.didispace.com/spring-boot-learning-21-1-3/)、[多环境的配置管理](http://blog.didispace.com/spring-boot-learning-24-1-4/)等等。 这些配置相关的知识都是Spring Boot原生就提供的，而今天我们将介绍的功能并非Spring Boot原生就支持，但却非常有用： 配置内容的加密 。 为什么要加密？ 可能很多初学者，对于配置信息的加密并不敏感，因为开始主要接触本地的开发，对于很多安全问题并没有太多的考虑。而现实中，我们的配置文件中，其实包含着大量与安全相关的敏感信息，比如：数据库的账号密码、一些服务的密钥等。这些信息一旦泄露，对于企业的重要数据资产，那是相当危险的。 所以，对于这些配置文件中存在的敏感信息进行加密，是每个成熟开发团队都一定会去的事。 如果您是DD的老读者，也许马上会想到Spring Cloud Config就提供配置的加密功能，之前在我的Spring Cloud系列教程和《Spring Cloud微服务实战》一书中都有详细的介绍，感兴趣的话可以点击[《Spring Cloud构建微服务架构：分布式配置中心（加密解密）》](https://blog.didispace.com/spring-cloud-starter-dalston-3-2/)一探究竟。 既然以前写过类似内容，那为什么还要写呢？因为并不是所有的开发场景都会搭建Spring Cloud的那套基础设施，同时也不一定会使用Spring Cloud Config作为配置中心。所以，本文主要说说，当我们只使用Spring Boot的时候，如何实现对配置中敏感信息的加密。 动手试试 下面我们将使用 https://github.com/ulisesbocchio/jasypt-s...

在使用Spring Boot开发应用的时候，你是否有发现这样的情况：自定义属性是有高量背景的，鼠标放上去，有一个 Cannot resolve configuration property 的配置警告。 如果不对于这个警告觉得烦，想要去掉，那么可以通过设置来去除： 但是，我的建议是不要去掉，因为这个警告正好可以通过高亮来区分你的自定义配置以及框架配置，可以让你快速的分辨哪些是自定义的。 如果你实在想去掉，那么也不建议用上面说的方法，而是建议通过完善配置元数据的方式来完成。所以，今天就来具体说说配置元数据的应用！ 啥是配置元数据？ 我们不妨打开一个已经创建好的Spring Boot项目，查看一下它的Spring Boot依赖包，可以找到如下图的一个json文件： 这里报错的就是配置的元数据信息。有没有发现这些 name 的值都很熟悉？其中 description 是不是也很熟悉？对，这些就是我们常用的Spring Boot原生配置的元数据信息。 这下知道配置元数据可以用来做啥了吧？它可以帮助IDE来完成配置联想和配置提示的展示。 而我们自定义配置之所以会报警告，同时也没有提示信息，就是因为没有这个元数据的配置文件！ 配置元数据的自动生成 既然知道了原理，那么接下来我们尝试用一下配置元数据试试！ 第一步 ：创建一个配置类，定义一个自定义配置 java @Data @Configuration @ConfigurationProperties(prefix = "com.didispace") public class DidiPro

前几天在[《Spring Boot 2.4 对多环境配置的支持更改》](http://blog.didispace.com/spring-boot-learning-24-1-4)一文中，给大家讲解了Spring Boot 2.4版本对多环境配置的配置变化。除此之外，还有一些其他配置变化，所以今天我们就继续讲讲其他的更新内容！ spring.profiles.include 对于这个配置项，你是否熟悉呢？从字面意思也不难理解，应该就是用来引入一些其他配置的配置（因为有个include嘛），实际作用也确实如此！ 当我们的应用有很多配置信息的时候，比如当用到了很多中间件MySQL、Redis、MQ等，每个中间件的配置都是一大串的，那么这个时候我们为了配置更简洁一些，可能就会对其做分组。 如果你有用过这样的配置方式，那么在升级2.4版本的时候一定要注意，因为原来的配置方法会失效！ 2.4之前的分组配置 先来看看2.4版本之前的分组配置，我们用下面这个例子来介绍： yml spring: profiles: active: "dev" --- spring.profiles: "dev" spring.profiles.include: "dev-db,dev-mq" --- spring.profiles: "dev-db" db: dev-db.didispace.com --- spring.profiles: "dev-mq" mq: dev-mq.didispace.com 其中： 1. 第一个 spring.profiles.active: dev ，代表默认激活 dev 配置 2. 第二段 dev 配置中使用了 spring.profiles.include 来引入其他配置信息，这里模拟一下一个是dev的db配置，一个是dev的mq配置。在2.3和之前版本的时候，我们通常就是这样来分组配置不同中间件的。 yml spring.profiles: "dev" spring.profiles.include: "dev-db,dev-mq" 文末我们提供一个样例工程，你可以通过修改spring boot版本到2.3和配置信息使用上面的样例，来启动应用看看这种配置效果。不出意外，你可以在启动

在目前最新的Spring Boot 2.4版本中，对配置的加载机制做了较大的调整。相关的问题最近也被问的比较多，所以今天就花点时间，给大家讲讲Spring Boot 2.4的多环境配置较之前版本有哪些变化。 多环境配置 2.4版本之前 先回顾下，2.4版本之前，我们在yaml配置文件中，使用 spring.profiles 来定义不同环境的标识，比如下面这样： yml spring: profiles: "dev" name: dev.didispace.com --- spring: profiles: "test" name: test.didispace.com --- spring: profiles: "prod" name: prod.didispace.com 2.4版本之后 而在本次2.4版本升级之后，我们需要将 spring.profiles 配置用 spring.config.activate.on-profile 替代，比如上面的配置需要修改为如下配置： yml spring: config: activate: on-profile: "dev" name: dev.didispace.com --- spring: config: activate: on-profile: "test" name: test.didispace.com --- spring: config: activate: on-profile: "prod" name: prod.didispace.com 指定环境启动 应用启动的时候，我们要加载不同的环境配置的参数不变，依然采用 spring.profiles.active 参数，对应值采用 spring.config.activate.on-profile 定义的标识名称。比如下面的命令就能激活 dev 环境的配置。 yml java -jar myapp.jar -Dspring.profiles.active=dev 在应用启动的时候，我们也能看到对应的配置激活日志： java 2020-12-16 16

在[快速入门](http://blog.didispace.com/spring-boot-learning-21-1-1/)一节中，我们轻松的实现了一个简单的RESTful API应用，体验了一下Spring Boot给我们带来的诸多优点，我们用非常少的代码量就成功的实现了一个Web应用，这是传统的Spring应用无法办到的，虽然我们在实现Controller时用到的代码是一样的，但是在配置方面，相信大家也注意到了，在上面的例子中，除了Maven的配置之后，就没有引入任何的配置。 这就是之前我们所提到的，Spring Boot针对我们常用的开发场景提供了一系列自动化配置来减少原本复杂而又几乎很少改动的模板化配置内容。但是，我们还是需要去了解如何在Spring Boot中修改这些自动化的配置内容，以应对一些特殊的场景需求，比如：我们在同一台主机上需要启动多个基于Spring Boot的web应用，若我们不为每个应用指定特别的端口号，那么默认的8080端口必将导致冲突。 如果您还有在读我的[Spring Cloud系列教程](http://blog.didispace.com/spring-cloud-learning/)，其实有大量的工作都会是针对配置文件的。所以我们有必要深入的了解一些关于Spring Boot中的配置文件的知识，比如：它的配置方式、如何实现多环境配置，配置信息的加载顺序等。 配置基础 在[快速入门](http://blog.didispace.com/spring-boot-learning-21-1-1/)示例中，我们介绍Spring Boot的工程结构时，有提到过 src/main/resources 目录是Spring Boot的配置目录，所以我们要为应用创建配置个性化配置时，就是在该目录之下。 Spring Boot的默认配置文件位置为： src/main/resources/application.properties 。关于Spring Boot应用的配置内容都可以集中在该文件中了，根据我们引入的不同Starter模块，可以在这里定义诸如：容器端口名、数据库链接信息、日志级别等各种配置信息。比如，我们需要自定义web模块的服务端口号，可以在 application.properties 中添加 server.por...

Spring Boot框架本身并没有对工程结构有特别的要求，但是按照最佳实践的工程结构可以帮助我们减少可能会遇见的坑，尤其是Spring包扫描机制的存在，如果您使用最佳实践的工程结构，可以免去不少特殊的配置工作。 典型示例 以下结构是比较推荐的package组织方式： js com + example + myproject + Application.java | + domain | + Customer.java | + CustomerRepository.java | + service | + CustomerService.java | + web | + CustomerController.java | root package ： com.example.myproject ，所有的类和其他 package 都在 root package 之下。 应用主类： Application.java ，该类直接位于 root package 下。通常我们会在应用主类中做一些框架配置扫描等配置，我们放在 root package 下可以帮助程序减少手工配置来加载到我们希望被 Spring 加载的内容 com.example.myproject.domain 包：用于定义实体映射关系与数据访问相关的接口和实现 com.example.myproject.service 包：用于编写业务逻辑相关的接口与实现 com.example.myproject.web ：用于编写Web层相关的实现，比如： Spring MVC 的 Controller 等 上面的结构中， root package 与应用主类的位置是整个结构的关键。由于应用主类在 root package 中，所以按照上面的规则定义的所有其他类都处于 root package 下的其他子包之后。默认情况下， Spring Boot 的应用主类会自动扫描 root package 以及所有子包下的所有类来进行初始化。 什么意思呢？举个例子，假设我们将 com.exam

简介 在您第1次接触和学习Spring框架的时候，是否因为其繁杂的配置而退却了？在你第n次使用Spring框架的时候，是否觉得一堆反复黏贴的配置有一些厌烦？那么您就不妨来试试使用Spring Boot来让你更易上手，更简单快捷地构建Spring应用！ Spring Boot让我们的Spring应用变的更轻量化。我们不必像以前那样繁琐的构建项目、打包应用、部署到Tomcat等应用服务器中来运行我们的业务服务。通过Spring Boot实现的服务，只需要依靠一个Java类，把它打包成jar，并通过 java -jar 命令就可以运行起来。这一切相较于传统Spring应用来说，已经变得非常的轻便、简单。 总结一下Spring Boot的主要优点： 为所有Spring开发者更快的入门 开箱即用，提供各种默认配置来简化项目配置 内嵌式容器简化Web项目 没有冗余代码生成和XML配置的要求 快速入门 本文我们将学习如何快速的创建一个Spring Boot应用，并且实现一个简单的Http请求处理。通过这个例子对Spring Boot有一个初步的了解，并体验其结构简单、开发快速的特性。 创建基础项目 Spring官方提供了非常方便的工具[Spring Initializr](https://start.spring.io/)来帮助我们创建Spring Boot应用。 使用Spring Initializr页面创建 第一步：访问Spring Initializr： https://start.spring.io/ 如图所示，几个选项说明： Project：使用什么构建工具，Maven还是Gradle；本教程将采用大部分Java人员都熟悉的Maven，以方便更多读者入门学习。 Language：使用什么编程语言，Java、Kotlin还是Groovy；本教程将采用Java为主编写，以方便更多读者入门学习。 Spring Boot：选用的Spring Boot版本；这里将使用当前最新的2.1.3版本。 Proje

这篇博文是临时增加出来的内容，主要是由于最近连载《Spring Cloud Alibaba基础教程》系列的时候，碰到读者咨询的大量问题中存在一个比较普遍的问题：版本的选择。其实这类问题，在之前写Spring Cloud基础教程的时候，就已经发过一篇[《聊聊Spring Cloud版本的那些事儿》](http://blog.didispace.com/springcloud-version/)，来说明Spring Boot和Spring Cloud版本之间的关系。 Spring Cloud Alibaba现阶段版本的特殊性 现在的Spring Cloud Alibaba由于没有纳入到Spring Cloud的主版本管理中，所以我们需要自己去引入其版本信息，比如之前教程中的例子： xml <dependencyManagement <dependencies <dependency <groupId org.springframework.cloud</groupId <artifactId spring-cloud-dependencies</artifactId <version Finchley.SR1</version <type pom</type <scope import</scope </dependency <dependency <groupId org.springframework.cloud</groupId <artifactId spring-cloud-alibaba-dependencies</artifactId <version 0.2.1.RELEASE</version <type pom</type <scope import</scope </dependency </dependencies </dependencyManagement 而不是像以

一 前言 最近通过深入学习Spring Cloud Gateway发现这个框架的架构设计非常简单、有效，很多组件的设计都非常值得学习，本文就Spring Cloud Gateway做一个简单的介绍，以及针对一次请求Spring Cloud Gateway的处理流程做一个较为详细的分析。 二 简介 Spring Cloud Gateway 即Spring官方推出的一款API网关，该框架包含了Spring5、SpringBoot2、Project Reactor，其中底层通信框架用的netty。Spring Cloud Gateway在推出之初的时候，Netflix公司已经推出了类似功能的API网关框架ZUUL，但ZUUL有一个缺点是通信方式是阻塞的，虽然后来升级到了非阻塞式的ZUUL2，但是由于Spring Cloud Gateway已经推出一段时间，同时自身也面临资料少、维护性较差的因素没有被广泛应用。 1 关键术语 在使用Spring Cloud Gateway的时候需要理解三个模块，即 Route ： 即一套路由规则，是集URI、predicate、filter等属性的一个元数据类。 Predicate ： 这是Java8函数式编程的一个方法，这里可以看做是满足什么条件的时候，route规则进行生效。 Filter ： filter可以认为是Spring Cloud Gateway最核心的模块，熔断、安全、逻辑执行、网络调用都是filter来完成的，其中又细分为gateway filter和global filter，区别在于是具体一个route规则生效还是所有route规则都生效。 可以先上一段代码来看看： java @RequestMapping("/paramTest") public Object paramTest(@RequestParam Map<String,Object param) { return param.get("name"); } @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("path

什么是WEB前端呢？就是用户电脑的浏览器所做的一切事情。我们来看看用户访问网站，浏览器都做了哪些事情： 输入网址 – 解析域名 请求页面 解析页面并发送页面中的资源请求 渲染资源 输出页面 监听用户操作 重新渲染。 通过上面的路径可以看出浏览器分为请求、传输、渲染三部分来实现用户的访问，本文就从这三个部分来浅析如何提升WEB前端性能。 一、请求 浏览器为了减少请求传输，实现了自己的缓存机制。浏览器缓存就是把一个已经请求过的Web资源拷贝一份副本存储在浏览器中，当再次请求相同的URL时，先去查看缓存，如果有本地缓存，浏览器缓存机制会根据验证机制（Etag）和过期机制(Last-Modified)进行判断是使用缓存，还是从服务器传输资源文件。具体流程如下图所示： 浏览器的请求有些是并发的，有些是阻塞的，比如：图片、CSS、接口的请求是并发；JS文件是阻塞的。请求JS的时候，浏览器会中断渲染进程，等待JS文件加载解析完毕，再重新渲染。所以要把JS文件放在页面的最后。 JS也可以通过两种方式由阻塞改成并行：一种是通过创建script标签，插入DOM中；另一种是在Script标签中增加async属性。 每种浏览器对同一域名并发的数量有限制，IE6/7是2，IE9是10，其他常见的浏览器是6，所以减少资源请求数量和使用多域名配置资源文件，能大大提高网站性能。 减少资源请求数量的方法，大致有以下几种： 1、通过打包工具，合并资源，减少资源数量。就是开发版本是很多个资源文件，部署的时候，按类合并成几个文件来输出。在实现模块管理的同时，实现统一输出。 2、CSS中，使用css sprite减少图片请求数量。 3、通过延迟加载技术，在用户无感知的情况下请求资源。 4、通过服务器配置，实现一次请求，返回多个资源文件，如淘宝CDN那样。 除了减少请求数量，也可以使用CDN镜像，来减少网络节点，实现快速响应。使用了CDN的请求，会根据用户所处的地理位置，找寻最近的CDN节点，如果请求是新的，则从资源服务器拷贝到节点，然后再返回

一、前言 如果你能够啃下教程一并且吃透原型链的几个概念的话说明你在前端飞仙的路上又进了一小步···学习最怕的不是慢而是站！这篇教程主要目的对原型链概念进一步加深理解 二、巩固下教程一的知识 来看下面的例子： js var text=new String("我是文字"); function Persion(name,job){ this.name=name; this.job=job; } Persion.myName="lxm"; Persion.prototype.sayName=function(){ alert(this.name)； } var perison1=new Persion("lxm","20") 思考：判断下列表达式返回的值： （两分钟之内对八道的算及格，剩下的同学回头接着理解教程一，传送门在此 [http://0313.name/2017/01/13/prototype-proto-constructor.html]） javascript perison1.__proto__ =Persion.prototype; perison1.name =Persion.name; perison1.prototype.__proto__ =Object.prototype; Persion.prototype.__proto__ =Object.prototype; Persion.__proto__ =Function.prototype; Persion.constructor =perison1; Function.__proto__ =Object.prototype; Function.prototype.__proto__ =Object.prototype; typeof Persion.prototype; typeof Function.prototype; 三、原型链图 这个图绝对是网络上独一无二独一份，此乃小米飞升教程独家秘籍！因为博主在学习过程中发现对文字的理解和记忆远远不如一个图来的更深更直观，更加透彻,为了您更好的学习原型链，博主特意花了一上午的时间用 mermaid 绘制了这个原型链的关系图，而且通过这个图我们能够发现