Spring Boot表单如何发送PUT/DELETE请求？HiddenHttpMethodFilter原理与配置-北京尧图网络

在 Spring Boot 里做传统页面开发时form 表单怎么发 PUT、DELETE 请求是很多全栈开发者都会碰到的一道坎。你可能遇到过一个很诡异的现象页面上明明写了form methoddelete打开浏览器开发者工具却发现发出去的是 POST后端 DeleteMapping 根本匹配不上控制台飘一个 405。问题根源其实很直接HTML 规范里 form 的 method 属性只支持 GET 和 POSTput 也好 delete 也好对浏览器来说都是不认识的值最终会被忽略甚至当成 GET 处理。这篇内容我会把这个问题讲透为什么会有这个限制Spring Boot 用什么机制把 POST 请求“翻译”成 PUT/DELETE怎么配置、怎么写表单、怎么调试最后把常见的坑整理成排查清单可以直接对照使用。1. 先搞清楚为什么 form 表单发不了 PUT/DELETE1.1 HTML 规范对 method 属性的约束很多初学者第一反应是“浏览器不认识 PUT 和 DELETE”其实不太准确。浏览器不是不认识 HTTP 方法而是 HTML 规范在设计 form 时就把 method 的枚举值限定成了 get 和 post 两个。任何其他值都是非法枚举浏览器遇到非法枚举会按默认情况处理也就是 GET。有个容易混淆的点如果用 JavaScript 去改 form 的 method 属性或者用 axios、fetch 调用接口浏览器是完全可以发出 PUT/DELETE 请求的。因为 XHR 和 fetch API 不受 HTML form 的限制它们是基于 HTTP 协议的客户端能力。真正被限制的只是form这个 HTML 元素的语义。所以当页面上写form methoddelete不要惊讶它会失败因为这样的写法从语法层面就不成立。如果服务端渲染过程中用了某些模板语法比如 Thymeleaf 的th:methoddelete它之所以能工作是因为 Thymeleaf 会把这个声明编译成“表单 method 保持 post再塞一个隐藏的_methoddelete参数”的处理而不是真的让浏览器发出 DELETE 请求。1.2 RESTful 风格让方法语义问题被放大早期互联网应用大多是 GET 拉页面、POST 提交数据表单天然够用。但后来大家开始设计 RESTful 接口用 URI 表示资源用 HTTP 方法表示动作GET 查询、POST 新增、PUT 更新、DELETE 删除甚至 PATCH 做部分更新。接口层这样做没问题因为前端调用接口的客户端axios、fetch、curl都不受 form 限制。难的是服务端渲染页面。运营后台、CMS 后台、老管理系统中前端往往就是一堆 HTML 模板配表单没有复杂的前端工程。这些场景里我们希望页面里删除一条数据就发出一个 DELETE 请求编辑保存就发出一个 PUT 请求这样 Controller 层面的路由可以写得很统一GetMapping、PutMapping、DeleteMapping 各管各的。但 HTML form 不给这个方法导致最自然的做法落空了。于是大家想了很多替代方案核心都是“曲线救国”把真正的方法语义通过另一个参数传递到服务端再由服务端还原。1.3 几种常见绕过方案怎么选实际项目里我见过这几类做法第一种用 JavaScript 拦截 submit改为 fetch/XHR 直接发出 PUT/DELETE。优点是 HTTP 协议层面就是真方法缺点是很依赖 JavaScript遇到禁用 JS 的浏览器或简单静态页面就失效而且还要处理按钮、回车提交、表单校验等细节。第二种把表单方法写成 POST但额外携带一个参数_methoddelete由服务端过滤器识别后把这次请求“伪装”成 DELETE。Spring MVC 的 HiddenHttpMethodFilter 干的就是这件事。优点是兼容所有浏览器不需要改前端逻辑缺点是严格来说浏览器发出的还是 POST需要通过约定让服务端明白真实意图。第三种不用 RESTful 风格继续 POST/user/delete这种 URL 表达动作。很多老项目是这么做的也能工作只是接口风格不统一。对比下来如果技术栈是 Spring Boot且以服务端渲染模板为主我通常推荐第二种也就是 Spring 官方提供的 HiddenHttpMethodFilter。它不侵入业务代码配置成本极低表单只要多一个隐藏字段即可。下面把这个机制拆开看。2. Spring Boot 的核心机制HiddenHttpMethodFilter2.1 它是怎么把 POST 翻译成 PUT/DELETE 的Spring Web 里有一个专门处理这个问题的过滤器类名叫 HiddenHttpMethodFilter父类是 OncePerRequestFilter所以一次请求最多执行一次。它的逻辑非常精简protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String paramValue request.getParameter(this.methodParam); // methodParam 默认是 _method if (POST.equals(request.getMethod()) StringUtils.hasLength(paramValue)) { String method paramValue.toUpperCase(Locale.ENGLISH); if (ALLOWED_METHODS.contains(method)) { // ALLOWED_METHODS 为 PUT、DELETE、PATCH HttpMethodRequestWrapper wrapper new HttpMethodRequestWrapper(request, method); filterChain.doFilter(wrapper, response); return; } } filterChain.doFilter(request, response); }关键点有三个。第一只有 POST 请求才会被检查。换句话说当表单提交 methodpost 并带上_methodput时这个过滤器才有机会生效。如果浏览器发的是 GET它不会管。第二它通过request.getParameter(_method)获取隐藏字段的值。这意味着_method既可以放在表单 body 里也可以放在 URL query string 里Spring 的请求参数解析会把两者合并在一起考虑。第三如果值不是 PUT、DELETE、PATCH 中的某个过滤器也不会做转换请求会继续往下走依然是 POST 语义。这样做是刻意保守的避免把任何随手写的参数都当成方法覆盖指令。转换的核心在于 HttpMethodRequestWrapper它继承自 HttpServletRequestWrapper只重写了一个方法private static class HttpMethodRequestWrapper extends HttpServletRequestWrapper { private final String method; public HttpMethodRequestWrapper(HttpServletRequest request, String method) { super(request); this.method method; } Override public String getMethod() { return this.method; } }一个 Servlet 请求对象里的getMethod()返回值被改写了后续 Spring MVC 在处理路由映射时调用request.getMethod()拿到的自然就是 PUT 或 DELETE于是PutMapping能匹配这个方法。服务器容器层面则完全不知道这个改动它只知道自己处理了一个 POST。2.2 Spring Boot 中怎么开启这个过滤器这是最容易踩坑的地方。Spring Boot 不同版本对这个过滤器的默认配置不一样。印象比较深的一次是某个项目从早期版本升级到 2.x升级后所有表单 delete/put 全部失效原因就是新版默认没有注册 HiddenHttpMethodFilter。为了不让版本问题干扰排错最稳妥的做法是在配置文件里显式打开spring.mvc.hiddenmethod.filter.enabledtrue在 Spring Boot 2.x 和 3.x 里这个配置项都是有效的。显式开启之后Spring Boot 会自动注册一个 OrderedHiddenHttpMethodFilter它的优先级设计得比较靠前能让后续的 Spring Security 过滤器链和 DispatcherServlet 都拿到转换后的方法。如果项目自定义了 HiddenHttpMethodFilter 类型的 Bean那么配置项是否开启已经不重要了因为你手动注册的 Bean 会替代自动配置。这个技巧后面讲自定义过滤器时还会提到。2.3 表单端和 URL 端到底怎么写先看最基本的 HTML 写法。编辑用户页面里要提交一个 PUT 请求form action/users/1 methodpost input typehidden name_method valueput / input typetext namename value张三 / input typeemail nameemail valuezhangsanexample.com / button typesubmit保存修改/button /form删除操作的表单更常见因为它往往只含一个按钮form action/users/1 methodpost styledisplay: inline input typehidden name_method valuedelete / button typesubmit删除/button /form_method的值大小写随意filter 内部会转成大写再比对所以 valueput 和 valuePUT 都行。如果用的是 Thymeleaf模板引擎提供了一种更简练的写法。th:methodput会自动生成一个名为_method的隐藏字段同时把表单的 method 属性固定为 postform th:action{/users/{id}(id${user.id})} th:methodput ... /form但我的建议是除非整个团队都很清楚 Thymeleaf 这个机制否则在页面里显式写input typehidden name_method valueput /虽然多一行排查问题时却少一层神秘感。尤其是从别的模板引擎比如 FreeMarker 或 JSP 切过来的项目显式写法思路完全一致一眼就能看到完整的请求参数。3. 完整实操一个最小可运行的用户 CRUD3.1 工程依赖和基础配置这里我不会引入数据库用一个内存 Map 当存储这样照着做起来不用搭库重点放在方法转换这条主线上。pom.xml 核心依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-thymeleaf/artifactId /dependencyapplication.propertiesspring.mvc.hiddenmethod.filter.enabledtrue spring.thymeleaf.cachefalse server.port8080spring.thymeleaf.cachefalse是开发期建议避免改模板后需要频繁重启才能看到变化。生产环境记得关掉或者交给运维配置。3.2 实体类和控制器User 实体public class User { private Long id; private String name; private String email; public User() {} public User(Long id, String name, String email) { this.id id; this.name name; this.email email; } // getter / setter 省略务必全部生成 }Controller 里我特意把方法映射写成 RESTful 风格Controller RequestMapping(/users) public class UserController { private final MapLong, User store new ConcurrentHashMap(); private final AtomicLong idGenerator new AtomicLong(1); GetMapping public String list(Model model) { model.addAttribute(users, store.values()); return list; } GetMapping(/new) public String createForm(Model model) { model.addAttribute(user, new User()); return form; } PostMapping public String create(User user) { long id idGenerator.getAndIncrement(); user.setId(id); store.put(id, user); return redirect:/users; } GetMapping(/{id}/edit) public String editForm(PathVariable Long id, Model model) { model.addAttribute(user, store.get(id)); return form; } PutMapping(/{id}) public String update(PathVariable Long id, User user) { user.setId(id); store.put(id, user); return redirect:/users; } DeleteMapping(/{id}) public String delete(PathVariable Long id) { store.remove(id); return redirect:/users; } }这个 Controller 里create 和 edit 共用了同一个模板文件通过判断传入的 user 是否为空来决定显示新建还是编辑状态。store 用 ConcurrentHashMap 是为了并发语义靠谱一点演示项目无所谓但别在生产环境用这种内存存储当持久层。3.3 模板页面写法list.html 负责展示列表和每行的操作按钮!DOCTYPE html html langzh-CN xmlns:thhttp://www.thymeleaf.org head meta charsetUTF-8 title用户列表/title /head body h1用户列表/h1 a th:href{/users/new}新增用户/a table border1 tr thID/th th姓名/th th邮箱/th th操作/th /tr tr th:eachuser : ${users} td th:text${user.id}1/td td th:text${user.name}张三/td td th:text${user.email}aexample.com/td td a th:href{/users/{id}/edit(id${user.id})}编辑/a form th:action{/users/{id}(id${user.id})} methodpost styledisplay:inline input typehidden name_method valuedelete/ button typesubmit删除/button /form /td /tr /table /body /htmlform.html 同时承接新增和编辑!DOCTYPE html html langzh-CN xmlns:thhttp://www.thymeleaf.org head meta charsetUTF-8 title用户表单/title /head body h1 th:text${user.id ! null} ? 编辑用户 : 新增用户表单/h1 form th:action${user.id ! null} ? {/users/{id}(id${user.id})} : {/users} th:method${user.id ! null} ? put : post input typehidden name_method th:if${user.id ! null} valueput/ div label姓名/label input typetext namename th:value${user.name}/ /div div label邮箱/label input typeemail nameemail th:value${user.email}/ /div button typesubmit保存/button /form /body /html注意这里把th:method和_method隐藏字段同时写了出来。严格来说 Thymeleaf 的th:methodput会自动补一个隐藏字段所以隐藏字段是重复的。我在生产环境一般只保留th:method但为了让读者不用关心模板的魔法行为示例里显式写了一遍。实际写代码时建议删掉重复隐藏字段只保留th:method或者只保留显式字段二选一。3.4 验证浏览器、命令和日志启动项目后访问http://localhost:8080/users可以执行完整的新增、编辑、删除流程。打开浏览器开发者工具的 Network 面板你会发现所有“编辑保存”“删除”请求的 HTTP Method 都显示为 POST但在 Payload 表单数据里有_methodput或者_methoddelete。这点非常重要能帮助你确认真正发送的流量长什么样避免和服务端认知不一致。如果想用命令行快速模拟可以用 curlcurl -X POST http://localhost:8080/users/1 \ -d _methodputname李四emaillisiexample.comcurl -X POST http://localhost:8080/users/1 \ -d _methoddelete注意这里必须用-X POST而不是-X PUT。因为服务端过滤器只认 POST 请求里的_method参数。如果你真的用-X PUT发请求请求体里的_methodput依然在可是过滤器根本不检查 PUT 请求Spring MVC 能不能把参数解析出来取决于 body 的 content type 和 form content filter。不建议把这种用法当常规方案。如果 Controller 的方法里打了日志你会看到PutMapping和DeleteMapping确实被触发了。这足以证明“翻译”完成。4. 各种坑从 405 到参数绑定失败4.1 405 错误排查清单表单提交后最常见的错误就是 405 Method Not Allowed。遇到这个状态码我通常按顺序查三件事。第一种情况HiddenHttpMethodFilter 没生效。配置文件里忘了加spring.mvc.hiddenmethod.filter.enabledtrue或者项目里的自定义过滤器覆盖掉了自动配置。排查方式很简单在表单提交后打印一下后端 Controller 收到的请求方法或者临时在过滤器链里打点。如果 Controller 根本没进那就说明请求方法不是预期值第一个嫌疑就是 filter 没挂上。第二种情况URL 路径没匹配上。比如表单action/users/edit后端却写的是PutMapping(/users/{id})那么请求进入 Spring MVC 后找不到对应的 PutMapping于是 405。这种问题跟 filter 无关是路由设计不一致。第三种情况_method参数名写错或者压根没传。有人会把隐藏字段 name 写成method而不是_method结果过滤器自然没反应请求保持 POST 语义同样会 405或者被某个 PostMapping 意外接收。405 的排查表整理如下现象可能原因解决提交后 Controller 未进入响应 405filter 未开启检查spring.mvc.hiddenmethod.filter.enabledtrue请求是 POST但找不到处理器URL 与 PutMapping 路径不一致统一 action 与映射路径过滤器不转换_method 参数缺失或 name 错误检查隐藏字段 name 是否为_method自定义过滤器优先级问题多个 filter 导致包装丢失确认自定义过滤器在正确的位置4.2 参数绑定方式为什么 RequestBody 经常拿不到数据这是新手最容易误解的地方。看到PutMapping下意识就在方法参数上写RequestBody User user然后发现请求参数始终是 null。问题的本质是这个请求从 HTTP 协议上看仍然是 POSTContent-Type 默认是application/x-www-form-urlencoded请求体是普通表单字符串。Spring MVC 的RequestBody会把请求体交给 HttpMessageConverter 去反序列化通常按 JSON 或 XML 来处理。面对name李四emaillisiexample.com这种字符串JSON 解析器根本没法工作轻则抛异常重则整个请求 400。在表单方法转换这个模式里正确的接收姿势是让 Spring MVC 做对象绑定也就是不写RequestBodyPutMapping(/{id}) public String update(PathVariable Long id, User user) { ... }Spring MVC 会拿请求参数去填充 User 对象的 setter。用ModelAttribute User user也是一样它是显式声明。这里隐含一个前提User 类必须有默认构造函数和对应的 setter。如果只关心一两个字段也可以直接用RequestParamPutMapping(/{id}) public String update(PathVariable Long id, RequestParam String name, RequestParam String email) { ... }总之“表单 POST _method 转换”这个组合本质上还是表单参数模型不是 JSON 模型。想接收 JSON就直接让前端用 fetch 发真正的 PUT不要走 form。4.3 中文乱码和过滤器顺序早期项目很容易出现中文乱码现象是表单提交后保存到数据库或者回显到页面时中文变成问号。根本原因在请求编码没有设置对。Spring Boot 里一般通过 CharacterEncodingFilter 强制请求和响应使用 UTF-8其顺序通常很高在 HiddenHttpMethodFilter 之前就已经工作所以只要按默认配置POST 表单的中文应该没问题。但如果自己注册了编码过滤器要记得把顺序放在所有业务过滤器之前因为只要后续还有读参数、写响应的环节编码不对后面再怎么补救都白搭。另外一个技巧是设置 Tomcat 的 URI 编码防止 URL query string 中文乱码。配置文件加server.tomcat.uri-encodingUTF-8现在默认已经是 UTF-8这行更多是为老项目定心用。4.4 和 Spring Security CSRF 的配合如果项目启用了 Spring Security 的 CSRF 防护表单方法转换要特别注意。CSRF Token 校验默认对所有非安全方法生效而经过 HiddenHttpMethodFilter 转换后的 PUT/DELETE 请求同样属于需要校验的方法。Thymeleaf 配合 Spring Security 时模板里可以直接用th:action配合隐藏的_csrf字段或者手动加input typehidden name_csrf th:value${_csrf.token} /必须保证这个字段和_method同时存在于同一个表单里否则 Security 会拦截请求。这不算 bug是安全设计。如果按照默认顺序HiddenHttpMethodFilter 会先于 Spring Security 的 filter chain 执行所以 Security 看到的请求方法已经是 PUT/DELETE它照样要求 CSRF token行为是一致的。反过来也没问题Security 看到的是 POSTPOST 也在校验范围内。两种顺序下你只需要提供 token。有一个容易忽略的点如果写了一个自定义 filter在_method转换之后又做了重定向或者包装了 request可能导致getParameter第二次拿不到 token这种坑比较隐蔽。排查 CSRF 问题时优先看表单实际提交的参数里有没有_csrf再考虑过滤器顺序。4.5 模板选择Thymeleaf 自动字段和原生 HTML 的差异Thymeleaf 的处理很贴心th:methodput会自动生成隐藏的_method字段这也是很多教程里直接写完就能跑的原因。但不熟悉这个机制的人看到页面渲染成form methodpost会一头雾水因为模板里写的明明是 put。所以我在团队内部约定除非有特殊原因表单里一律显式写隐藏字段模板生成的结果就是最终的 HTTP 请求内容避免“魔法”。用原生 HTML 页面时form 的 action 必须指向后端接口隐藏字段直接写在 HTML 文件里就行form actionhttp://localhost:8080/users/1 methodpost input typehidden name_method valueput/ input typetext namename/ button保存/button /form这种写法不依赖任何模板引擎只要后端 filter 开启一样生效。用 JSP、FreeMarker 也同理核心就是隐藏字段加 POST 表单。5. 方案背后的权衡和进一步扩展5.1 为什么它适合传统页面项目HiddenHttpMethodFilter 这套方法转换机制在服务端渲染的老项目中几乎是成本最低的解法。优点很明确不要求前端工程化不依赖 JavaScript表单怎么写、传什么参数服务端一目了然路由可以完全按 RESTful 语义组织Controller 代码更统一。缺点也不能忽略。浏览器真正发出的请求始终是 POST这在严格的 API 网关日志或者服务端审计里记录的 HTTP Method 不是业务语义上的方法。如果团队要求严格的 HTTP 语义表单转换只能算一种“兼容层”不能替代协议层的方法表达。另外跨域、网关、防火墙等中间件如果针对 PUT/DELETE 有特殊策略它们看到的是 POST可能不会执行那些策略。反过来如果因为中间件把 PUT 请求拦截了而这个页面实际是 POST反而能通过。这个特性算优点还是缺点看具体场景。5.2 如果项目想自定义参数名或逻辑怎么做默认的_method参数名是框架规定的。如果因为某些原因想换一个名字或者想支持自定义方法可以通过实现 Filter 来覆盖默认逻辑。甚至不用 Spring 的过滤器自己在 Controller 里读参数也能做但那就把通用逻辑散落到各个方法里了不推荐。给一个最小自定义过滤器示例Component public class HttpMethodOverrideFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { if (POST.equalsIgnoreCase(request.getMethod())) { String override request.getParameter(_method); if (override ! null !override.isBlank()) { String method override.toUpperCase(Locale.ENGLISH); if (method.equals(PUT) || method.equals(DELETE) || method.equals(PATCH)) { HttpServletRequestWrapper wrapper new HttpServletRequestWrapper(request) { Override public String getMethod() { return method; } }; chain.doFilter(wrapper, response); return; } } } chain.doFilter(request, response); } }这个代码只是为了展示原理。实际项目里我通常不推荐自己实现直接用 Spring 官方的 HiddenHttpMethodFilter维护成本低行为也经过大量测试。只有一种情况例外你需要同时支持 GET 请求也带_method参数做转换这时官方 filter 不会处理才需要自定义。5.3 API 层和现代前端建议走真正的 HTTP 方法如果界面已经不是传统服务端渲染页面而是 Vue、React 这类工程直接用 fetch 或者 axios 发真正的 PUT/DELETE 请求更干净。前端框架完全有能力发出任意 HTTP 方法不需要_method参数和隐藏字段。那么什么时候还会用到本文这套我见过最多的是这些场景老系统改造前后端还没分离运维脚本需要临时模拟删除动作以及一些低代码平台仍然靠 form 表单提交数据。在这些场景里表单方法转换是兼容旧世界的窗口。如果用 fetch 发真正的 PUT 请求又要提交application/x-www-form-urlencoded格式后端接收参数时要考虑 FormContentFilter。Spring Framework 5.1 之后提供的 FormContentFilter会把 PUT/PATCH 请求体里的表单内容解析进参数列表所以RequestParam也能用上。但我的建议是新接口直接用 JSON别再用 form 格式混搭避免踩消息转换的坑。5.4 一个可以立刻落地的公共模板片段如果已经决定在项目里统一用表单方法转换我建议把隐藏字段封装成一个模板片段不要每个页面手写。Thymeleaf 里可以这样定义 fragments/methods.htmlth:block th:fragmentmethod(methodName) input typehidden name_method th:value${methodName} / /th:block其他页面引入form th:action{/users/{id}(id${user.id})} methodpost th:block th:replace~{fragments/methods :: method(put)}/th:block ... /form这样做的好处是以后要调整参数名或者统一加逻辑只需要改一个地方。团队新人也少踩坑因为看到的是明确的隐藏字段而不是模板引擎的魔法。在实际项目里我还会刻意把删除按钮放进内联 form并加一个二次确认事件。因为删除是危险操作表单里只有_methoddelete一个参数加确认后误触概率会低很多。细节虽小但运营后台每天被删的数据都是大事。最后分享一个排查工具的小技巧遇到表单方法转换相关的疑难杂症别光看后端日志先在浏览器开发者工具里看清请求方法和请求参数再对比服务端实际进入的方法。很多时候问题不在服务端逻辑而是前端表单没有生成预期的隐藏字段或者 URL 不匹配。把这两层对齐问题基本就解决了。这个模式在维护过几个老管理后台项目之后我越发觉得值得坚持。

Spring Boot表单如何发送PUT/DELETE请求？HiddenHttpMethodFilter原理与配置

相关推荐

Dinic最大流算法详解：分层图、多路增广与当前弧优化

ReactDOMRoot源码解析：从createRoot到render的完整链路

MySQL学生选课系统源码实战：表结构设计与事务并发控制

更多资讯

大模型Skills是什么？从设计到落地的完整指南

基于STM32与HX711的智能体重秤：从原理图到低功耗实现

MATLAB异常检测工具箱实战：从算法选型到参数调优的完整指南

AI时代前端生态迁移：从Vue到React的双语能力构建

机器人嵌入式岗位重新定价：STM32贬值，系统能力吃香

Oracle 9i补丁9.2.0.8在Windows 32位上的安装与避坑全解析

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？