企业官网建设流程全解析

接手过不少半路出家的SpringMVC项目，也面试过很多候选人，我发现在“请求参数接收”这块，真正能讲透、遇到问题能快速定位的人还真不多。多数人停留在“会用@RequestParam和@RequestBody”的阶段，但对参数到底是怎么从HTTP请求走到Controller方法入参的、为什么有时候参数收不到、为什么JSON格式的Body死活绑定不上，往往一脸懵。

这篇文章就把SpringMVC请求参数接收这件事从头到尾拆一遍。从底层原理讲到常用注解，从简单类型到复杂对象，再配合拦截器、参数校验和乱码处理这些实战中绕不开的点，最后整理一份问题排查清单。你可以把它当作一份实操笔记，遇到问题回来翻一翻，比去翻源码高效得多。

1. 先搞懂参数接收在SpringMVC工作流程中的位置

1.1 SpringMVC一次请求的完整链路

要理解参数接收，先得知道它发生在哪一步。SpringMVC的完整工作流程大概是这样的：

DispatcherServlet收到请求后，先通过HandlerMapping找到对应的HandlerMethod（也就是我们写的Controller方法），然后通过HandlerAdapter去执行这个方法。在执行方法之前，有一个非常关键的步骤——参数解析。SpringMVC会遍历方法的每个参数，找到合适的HandlerMethodArgumentResolver（参数解析器），把HTTP请求里的内容转换成Java对象，再传给方法。

参数解析完之后，才真正进入Controller方法体。方法执行完返回ModelAndView或响应体，经过视图解析、渲染，最终把响应写给客户端。

重点是：参数接收是方法执行前的准备工作。这个阶段出问题，方法根本不会进，抛出的往往是“Required request parameter ... is not present”或者“HttpMessageNotReadableException”这类的异常。

1.2 底层核心：HandlerMethodArgumentResolver

SpringMVC的参数接收建立在HandlerMethodArgumentResolver这个接口之上。它的核心作用就一句话：判断当前参数类型支不支持解析，以及怎么从请求中取出值转成这个参数类型。

public interface HandlerMethodArgumentResolver { boolean supportsParameter(MethodParameter parameter); Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception; }

SpringMVC内置了一大堆实现类，比如RequestParamMethodArgumentResolver（处理@RequestParam）、PathVariableMethodArgumentResolver（处理@PathVariable）、RequestResponseBodyMethodProcessor（处理@RequestBody）、ServletModelAttributeMethodProcessor（处理对象绑定）等等。这些解析器组成了一个责任链，Spring会按顺序逐个调用supportsParameter判断是否能处理当前参数，找到第一个能处理的就去执行。

这也是为什么不能在一个方法里把@RequestParam和@RequestBody混用在同一参数上——解析器是按注解和类型来匹配的，混用会让Spring找不到合适的处理器，或者绑定的结果完全不是你想要的。

清楚了这个机制，后面所有的细节就都好理解了。

1.3 为什么说参数接收是前后端联调的重灾区

前后端联调时，参数接收不顺利往往不是后端代码写错了，而是前端传的参数格式和后端期望的格式不一致。常见的有这几种：

• 前端用POST + JSON格式发数据，后端用@RequestParam接收，结果啥也收不到。
• 前端用表单格式（application/x-www-form-urlencoded）提交，后端用@RequestBody接收，同样绑定不上。
• 前端传的日期字符串是“2024-12-01 10:30:00”，后端用Date类型接收，直接报400。

这些问题的根源在于SpringMVC区分参数解析方式的核心依据是请求头Content-Type和参数注解。弄懂这个对应关系，联调效率能提高一半。后面第3部分会详细展开。

2. 最常用的参数接收注解详解

2.1 @RequestParam：URL参数和表单参数的接收

@RequestParam是使用频率最高的参数接收注解，它处理的是两种数据：URL查询字符串参数（如?page=1&size=10）和表单格式的请求体参数（Content-Type为application/x-www-form-urlencoded或multipart/form-data）。

@GetMapping("/list") public Result list(@RequestParam("page") Integer page, @RequestParam(value = "size", defaultValue = "10") Integer size) { // 业务逻辑 }

这个注解有几个关键属性，务必记清楚：

• value/name：参数名，对应请求中传的参数名。
• required：是否必传，默认true。参数缺少时抛出MissingServletRequestParameterException。
• defaultValue：默认值。设置后required自动失效，参数没传就用默认值。

实际开发中，分页参数、搜索条件、筛选状态这类场景都适合用@RequestParam。如果参数是必填的，就不要给defaultValue，让Spring强制校验；如果不是必填，设置required=false或给defaultValue都可以，但两者有个细微区别：前者在参数不存在时得到null，后者得到默认值。业务上如果需要区分“没传”和“传了空字符串”，建议用required=false，因为空字符串传给Integer参数会抛出NumberFormatException。

这里有个非常典型的坑：前端传参时把空字符串当作“没有值”，比如?size=。此时Spring会尝试把空字符串转成Integer，直接抛出异常。解决办法有两个：一是用defaultValue兜底，但空字符串同样覆盖不了；二是写一个自定义Converter或ControllerAdvice统一处理空字符串到null的转换。实际项目中我倾向于在全局配置里加一个StringToNumber的转换器，把空字符串视为null。

2.2 @PathVariable：RESTful风格路径参数

路径参数和查询参数是两种完全不同的传参方式。@PathVariable从URL模板中提取值，配合@GetMapping("/user/{id}")这类路径使用：

@GetMapping("/user/{id}") public Result getUser(@PathVariable("id") Long id) { // 按id查询 }

这里必须区分清楚：@PathVariable解决的是“资源定位”问题，@RequestParam解决的是“条件过滤”问题。比如/user/1001是定位到id为1001的用户，后面跟的?fields=name,email才是过滤返回字段。混用当然可以，但要保持语义清晰。

路径参数的常见问题：

1. 路径中包含特殊字符，比如/file/{name}，文件名里带.或/会被截断或解析异常。如果文件名允许特殊字符，建议在Controller层做URL解码，或者干脆用查询参数传。
2. 路径参数值经过URL编码后，Spring默认会做一次解码，但如果前端做了双重编码，后端拿到的是错误的值。
3. 参数类型不匹配，比如路径模板是{id}，传了个非数字，Spring抛出MethodArgumentTypeMismatchException。需要全局异常处理器统一兜底，返回400而不是500。

2.3 @RequestHeader和@CookieValue：从请求头和Cookie中取值

有的参数不在URL里，也不在Body里，而是在请求头中。典型场景：token鉴权、客户端类型标识、分页信息放在自定义Header中。

@GetMapping("/info") public Result info(@RequestHeader("X-Client-Type") String clientType, @RequestHeader(value = "X-Request-Id", required = false) String requestId) { // 使用请求头参数 }

@CookieValue则用于获取Cookie中的值，比如自动登录的token：

@GetMapping("/auto-login") public Result autoLogin(@CookieValue(value = "token", required = false) String token) { // 用token做自动登录 }

这两个注解用法上和@RequestParam几乎一致，也支持required和defaultValue。区别就是值的来源不同。很多初学者容易忽略的是：Header中的值默认按字符串处理，如果你要接收一个数字类型的Header，Spring也会自动做类型转换，但转换失败时会抛异常。

实际联调中，自定义Header还有一个坑：跨域场景下，前端自定义Header会触发OPTIONS预检请求。如果后端没有处理好OPTIONS请求，会导致真实请求发不出去或Header丢失。所以用了自定义Header，一定要配合CORS配置一起处理，别等联调时才想起来。

2.4 参数名不一致时的处理

前端传的参数名和后端方法参数名不一致，是最常见的场景。比如前端约定传user_name，后端变量名是username。解决办法很简单：

@RequestParam("user_name") String username

或者用注解的name属性：@RequestParam(name = "user_name") String username。其实这里有一个隐藏的知识点：如果用IDE编译时带了-parameters参数，Spring可以通过字节码参数名拿到变量名，省略value属性直接绑定。但实际项目中很少依赖这个，一是前端约定的参数名未必和Java变量名一致，二是显式声明可读性更好。所以我的建议是：凡是前后端联调的接口，参数名一律显式写清。

还有一种情况：接口升级时，前端新旧版本传的参数名不同，可以用@RequestParam配合@RequestMapping的params属性做版本区分，而不是在一个方法里兼容两套名字。参数解析逻辑越简单，后面维护越省心。

3. 复杂参数接收：对象绑定、JSON、数组和集合

3.1 POJO对象绑定：多个参数组成的对象

实际业务中很少一个接口只收三五个参数，更多的情况是几十个字段。这时用@RequestParam一个个列出来不现实，Spring提供了对象绑定机制。当Controller方法参数是一个自定义POJO且没有加任何注解时，Spring会把它当作数据绑定对象，自动从请求参数中匹配同名字段进行赋值。

@Data public class UserQuery { private String name; private Integer age; private String email; } @GetMapping("/search") public Result search(UserQuery query) { // query.name、query.age 已被自动绑定 }

对象绑定有几个进阶技巧：

• 级联属性绑定：内部对象属性通过“对象名.属性名”传参，比如user.name、user.age，Spring会把它绑定到UserQuery里的user属性上。
• List和Map属性：List绑定用hobbies[0]、hobbies[1]；Map绑定用attributes[key]。
• 布尔类型：前端传flag=true或flag=1都可以转成Boolean。
• 日期类型：需要配合@DateTimeFormat指定格式，否则Spring只能用默认的日期格式解析，大概率报错。

对象绑定的优势是代码简洁，但它也有代价：字段多了以后，前端很难知道哪些字段可以传，后端也不好做校验。所以实际项目中我建议引入专门的DTO类，配合@Valid做参数校验，而不是直接用实体类接收。实体类接收请求参数是典型的坏味道——数据库字段暴露给前端，后续改表结构还容易影响接口兼容性。

3.2 数组、List和Map参数接收

前端批量操作时经常传数组，比如批量删除用户，传一组id。接收方式有几种：

1. 简单数组类型：@RequestParam("id") Long[] ids。前端传id=1&id=2&id=3或ids[]=1&ids[]=2（后者需要稍微处理）能成功绑定。
2. List类型：@RequestParam("id") List<Long> ids。用法类似。
3. 对象数组：@RequestBody List<UserDTO> users。这个必须走JSON，表单格式绑定不上。

数组和List接收的关键还是Content-Type。GET请求用查询参数重复传同名字段可以绑定到数组；POST表单格式也可以；但JSON数组就必须用@RequestBody。

Map接收是个特例。直接用@RequestParam Map<String, String>可以接收全部请求参数，适合参数不固定的场景。但这种做法可维护性差，一般只建议用在“过滤条件动态拼接”这类场景。如果你要用Map接收JSON对象，要用@RequestBody Map<String, Object>，但此时参数内部的值类型需要自己处理，Jackson默认转成LinkedHashMap或对应的Java类型。

3.3 @RequestBody：JSON请求体的绑定

@RequestBody是前后端分离项目里用得最多的参数接收方式。它和前面几种有本质区别：前面的方式都是基于“键值对”的表单数据，@RequestBody针对的是请求体的整体内容，通常搭配JSON格式使用。

@PostMapping("/save") public Result save(@RequestBody @Valid UserDTO user) { // 直接使用绑定好的UserDTO }

它的底层工作流程是这样的：HandlerAdapter找到RequestResponseBodyMethodProcessor这个解析器，它把请求体内容交给HttpMessageConverter接口的实现类去转换。SpringMVC默认注册了Jackson的MappingJackson2HttpMessageConverter（如果项目引入了jackson-databind），它负责把JSON字符串反序列化成Java对象。

这里有三件事必须注意：

1. Content-Type必须是application/json。如果前端用了application/x-www-form-urlencoded，即使Body里是一段JSON字符串，@RequestBody也拿不到内容。
2. 必须引入Jackson依赖且版本要兼容。Spring Boot 2.x默认带了jackson-databind，但老一点的SpringMVC XML配置项目里可能没配消息转换器，会报HttpMediaTypeNotSupportedException或No converter found for return value type。
3. JSON字段名和Java属性名必须对得上。Jackson默认按属性名匹配，如果前端传的是user_name而后端属性是userName，绑定就是null。解决方式是加@JsonProperty("user_name")注解或者全局配置SNAKE_CASE策略。

JSON请求体绑定失败时的报错信息经常是JSON parse error，这类问题在排障时优先看三件事：请求的Content-Type是不是application/json；Body内容是不是合法的JSON；字段名是否匹配。按照这个顺序排查，90%的问题能快速定位。

3.4 日期、数字等类型转换问题

SpringMVC在做参数绑定时，最后一步是类型转换。从HTTP请求拿到的原始参数全是字符串，把字符串转成Integer、Long、Date、BigDecimal，靠的是Spring的ConversionService体系。

先说数字类型。整数、小数、布尔这些内置转换器都很成熟，基本不会出问题，但有几个容易踩的坑：

• 空字符串转数字：上面提到过，直接报NumberFormatException。
• 前端传带千分位的数字字符串“1,234”，转换失败。需要自定义转换器去掉分隔符。
• 浮点数精度问题：接收金额不要用Double，用BigDecimal。

日期类型比较麻烦。SpringMVC默认能解析的日期格式是yyyy/MM/dd（不是我们习惯的yyyy-MM-dd）。要支持自定义格式，有三种方案：

方案一：在字段上加@DateTimeFormat注解。

public class UserQuery { @DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss") private Date createTime; }

方案二：全局配置统一日期格式。Spring Boot项目中可以写一个WebMvcRegistrations或自定义Converter。

方案三：用Jackson的@JsonFormat配合@RequestBody。注意：@JsonFormat是Jackson处理JSON反序列化时用的，@DateTimeFormat是Spring处理表单格式绑定时用的，两者不是一回事。如果一个接口既支持表单格式又支持JSON格式（实际项目中这种情况不少），两个注解都要加。

public class UserDTO { @DateTimeFormat(pattern = "yyyy-MM-dd") @JsonFormat(pattern = "yyyy-MM-dd") private LocalDate birthday; }

日期这块我特别推荐用LocalDate、LocalDateTime替换老的java.util.Date，配合jackson-datatype-jsr310模块，处理起来更优雅，不会有时区和可变性问题。

4. 参数校验、拦截器配合与实战场景

4.1 用@Valid对接收的参数做校验

参数接收不仅要把值取出来，还要保证值合法。SpringMVC的校验机制基于JSR-303规范（Hibernate Validator是它的参考实现）。用法很简单：

@Data public class UserDTO { @NotBlank(message = "用户名不能为空") @Size(max = 20, message = "用户名长度不能超过20") private String name; @Min(value = 1, message = "年龄最小为1") @Max(value = 150, message = "年龄最大为150") private Integer age; @Email(message = "邮箱格式不正确") private String email; } @PostMapping("/save") public Result save(@RequestBody @Valid UserDTO user) { // 校验通过才执行到这里 }

注意：@RequestBody的参数加@Valid，校验失败时抛出MethodArgumentNotValidException；表单绑定的POJO加@Valid，校验失败时抛出BindException。两个异常类型不同，在全局异常处理器里都要处理。

校验注解列表很多：@NotBlank、@NotEmpty、@NotNull、@Size、@Min、@Max、@Pattern等等。用起来不难，但有几个容易忽略的细节：

1. @NotBlank和@NotNull的区别：@NotBlank会去掉首尾空格再判断，能拦住“纯空格”的值；@NotNull只判null。
2. 级联校验：如果DTO内部还有对象，内部对象的字段要加@Valid，否则不会递归校验。
3. 分组校验：同一个DTO在不同接口中校验规则不同（比如新增时id必填、修改时id选填），可以用分组功能。实际项目里我常用group属性区分新增和更新场景。

参数校验写得好不好，直接决定Controller里有没有一堆if判断。把校验规则放到DTO注解上，代码会清爽很多。

4.2 拦截器在参数处理链路中的位置和配合方式

参数接收的准备工作发生在HandlerAdapter执行方法时，而拦截器的preHandle方法在HandlerAdapter执行之前调用。所以拦截器能做很多参数接收前的统一处理，比如：

• 身份鉴权：从Header或Cookie中取出token，校验通过才放行。
• 参数预处理：给request设置attribute，供Controller方法读取。
• 日志记录：记录请求参数、处理时长。
• 接口幂等性校验：从参数中提取业务主键，查redis判断是否重复请求。

拦截器配置：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/login", "/api/register"); } }

一个常见的困惑是：拦截器和参数接收到底什么关系？拦截器在参数解析之前执行，所以拦截器里拿不到Controller方法入参里绑定好的对象，但可以直接操作HttpServletRequest拿到原始请求参数。很多时候我们可以在拦截器里做安全校验，拦截非法请求，不让它走到参数解析那一步。

这里要特别提醒一个“坑中坑”：拦截器里不要轻易修改请求参数。Servlet规范里的request.getParameter()只能读不能写，修改参数需要包装Request对象重写getParameter方法。这是一个复杂的操作，如果只是添加一个临时参数，建议用request.setAttribute("key", value)而不是试图改参数Map。业务代码里用@RequestAttribute注解取出即可。

拦截器配合参数接收还有一个高频场景：在拦截器中校验签名。前端请求会带一个签名参数，后端用相同密钥和请求参数算出签名比对。这种情况下，拦截器要读取请求体中的参数做签名运算，但请求体是一段流，Controller里的@RequestBody也要读同一段流，两者会冲突——流只能读一次。解决办法是包装Request，提前把Body缓存成字节数组，后续的getInputStream或getReader都从这个缓存中读取。这是一个很重要的实战技能，前后端联调遇到签名校验加JSON请求体时几乎必然要用到。

4.3 不同前后端交互场景下该怎么设计参数接收

实际项目中，参数接收方式的选择有一套约定俗成的经验。根据不同的交互场景，我的推荐方案如下：

这套方案不是绝对标准，但它能覆盖绝大多数业务场景，而且让前后端联调时有据可依。最怕的是同一个项目里不同开发各写各的，一会儿@RequestParam、一会儿@RequestBody，甚至同一个接口既想要自由表单又想要JSON，这种设计很混乱，建议从项目规范上就定死。

4.4 Content-Type与接收方式的对应关系

理解Content-Type与接收方式的对应关系，是排障的关键。我整理了一张对照表：

很多参数接收问题的排查思路，其实就是这张表。前端说“我传了参数但是后端没收到”，先确认Content-Type是哪个，再看后端用了什么注解，两者不匹配就一定能找到问题所在。

顺便提一句：@RequestBody本身不关心Content-Type是application/json还是application/xml，它决定的是消息转换器。如果Body内容格式和Content-Type不匹配（比如Content-Type是application/json但里面是XML），一样会报解析错误。保持请求头、Body内容、后端注解三者一致，是参数接收不出问题的根本原则。

5. 常见问题与排查技巧实录

5.1 问题一：Required request parameter is not present

这是出现频率最高的参数接收报错。字面意思：某个标了required=true的@RequestParam参数没有传。

排查顺序：

1. 看前端请求URL中确实没有这个参数。用浏览器F12打开Network面板，确认实际发出的请求。
2. 确认参数名拼写一致。大小写、下划线都要对比。
3. 确认请求方式匹配。比如Controller是@GetMapping，前端却发了POST请求。
4. 确认Content-Type。如果有请求体但用的不是表单格式，@RequestParam也会收不到。
5. 特殊情况：POST请求中，参数在URL查询字符串上，后端用@RequestBody接收，那是另一套机制，@RequestParam能拿到URL上的值，但仅限URL，RequestBody拿的是Body里的内容。两者别搞混。

这个报错的好处是Spring很明确地告诉了你哪个参数缺失，按上面顺序排查通常几分钟就能解决。

5.2 问题二：JSON请求体绑定不上，接收对象全是null

前端明确用了application/json，后端方法也标了@RequestBody，但进入方法后对象的字段全是null。这类问题排查要点：

1. 字段名匹配。前端传nickName，后端属性是nickname，大小写不同，绑定就是null。
2. 序列化策略不一致。Jackson配置了CAMEL_CASE_TO_SNAKE_CASE策略，但前端没按snake_case传，就会失配。
3. 无参构造函数缺失。Jackson反序列化时默认使用无参构造函数创建对象，如果DTO只有有参构造函数且没有默认构造，Jackson会失败。报错往往是InvalidDefinitionException。
4. 类型不匹配。前端传{"age": "十八"}，后端age是Integer，反序列化失败。
5. 未知字段。默认情况下Jackson忽略未知字段，不会报错，但如果全局配置了FAIL_ON_UNKNOWN_PROPERTIES=true，多传字段反而会导致400。

我的经验是：一旦出现全部null，第一反应先看Jackson日志，第二看字段命名。如果项目中有多套命名风格混用，可以全局设置一个统一的PropertyNamingStrategy，前后端约定一致，一劳永逸。

5.3 问题三：中文参数乱码

乱码问题在参数接收里属于“低级但高发”的问题。分两种情况：

• GET请求中的中文参数：需要配置Tomcat的URIEncoding为UTF-8。
• POST表单中的中文参数：需要配置CharacterEncodingFilter，强制使用UTF-8编码。

Spring Boot中推荐使用CharacterEncodingFilter，并且设置forceEncoding为true。还有一个容易忽略的点：Tomcat高版本默认URI编码已是UTF-8，但如果你用了自定义的Connector配置，要留意是否改动了编码。另外，前端发送请求时也要保证URL编码正确，特别是用原生JavaScript拼接URL时，中文需要encodeURIComponent。

如果是JSON请求体出现乱码，问题往往在服务端的响应编码设置，请求体编码本身由Content-Type的charset决定。发送方在请求头里指定charset=UTF-8，接收方按UTF-8解码，就能避免。

5.4 问题四：日期格式解析失败

日期解析失败报的是MethodArgumentTypeMismatchException或HttpMessageNotReadableException。排查时先看报错信息里的解析格式：

• 表单格式：看有没有@DateTimeFormat，没有的话Spring尝试用默认的Locale格式解析，大概率失败。
• JSON格式：看有没有@JsonFormat，没有的化Jackson按ISO-8601标准解析，我们习惯的“2024-12-01 10:30:00”是解析不了的。

我的建议是全局定义一套统一日期格式，表单和JSON各配一个转换器/反序列化器。Spring Boot中可以自定义Jackson的ObjectMapper配置，给LocalDateTime和Date都注册自定义的Deserializer。这样项目中所有接口的日期格式都是统一的，不会出现这个接口要传这种格式、那个接口要传另一种格式的混乱局面。

5.5 问题五：对象绑定失败，进入方法时发现参数是null或被截断

对象绑定（POJO接收）失败的常见原因：

1. 前端传的参数名和DTO字段名不一致。这种场景最容易发生在“驼峰转下划线”的约定没对齐时。
2. DTO没有提供setter方法。Spring数据绑定靠setter或直接字段访问，如果用@Getter替代@Setter，withoutSetter的字段就绑定不上。
3. 内部嵌套对象没绑上。前端传了user.name，但DTO里user属性是null，说明嵌套对象的初始化或绑定规则有问题。可以给user字段一个默认new实例，或者检查级联绑定参数名。
4. 多级嵌套层级太深。Spring数据绑定对深层级联支持有限，超过两三层建议直接用JSON格式。

排查这类问题，最快的办法是写一个测试接口，用curl模拟请求打印所有收参，逐个字段核对。如果不想影响线上，也可以用单元测试MockMvc直接模拟请求，把参数绑定链路单独验证一遍。

5.6 附：参数接收问题排查速查表

收到请求后如果一时定位不到原因，建议先做一个“裸奔测试”：写一个临时Controller方法，参数用HttpServletRequest直接把所有参数打出来，看原始请求到底带了什么。这一步能快速区分问题出在前端还是后端，省得猜来猜去。

写在最后

说句实在话，SpringMVC参数接收本身不难，难的是把“HTTP协议特性”、“Spring绑定机制”和“前后端交互习惯”这几样东西串起来理解。我见过太多开发只记注解用法，不关注Content-Type和消息转换器，出了问题只能google报错信息，运气好能解决，运气不好就卡几个小时。

我个人在实际项目中的一个习惯是：每个接口写完，先用curl或Apifox完整测一遍所有传参形式。GET参数、表单参数、JSON参数各测一次，确认每种格式下都能正确接收，再交给前端联调。这个习惯帮我挡掉了大量联调阶段的低级问题。

如果你正在维护老项目，里面有一堆历史遗留的“玄学传参”，别急着大改。先按这篇文章里的排查清单理一遍，找到根因后再针对性地修。参数接收的坑大多是重复的，踩过一次，记住规律，以后就能避开。希望这篇笔记能让你少踩几个坑。