1. GET 与 POST 的本质差异别再只会说“查和改”很多人聊到 GET 和 POST第一反应就是“GET 拿数据POST 提交数据”。这话没错但太粗了。我在面试前端候选人的时候经常问一个问题“你现在要给后端传一个很长的数组用 GET 还是 POST”十个里有八个说用 POST理由是“怕 URL 太长放不下”。但你再问他 POST 就一定安全吗GET 就一定比 POST 快吗他又答不上来。这就说明我们对这两个最基础的请求方法其实停留在“背结论”的阶段没有真正理解它们在设计层面的差别。这里的核心关键词是语义。HTTP 协议设计 GET 和 POST从来不是为了区分“长参数”和“短参数”而是为了表达客户端对资源的操作意图GET 是安全且幂等的读操作POST 是可能产生副作用的写操作。你带着这套语义去看问题很多“该用哪个请求方式”的争论就自然消失了。1.1 语义层面同一份数据不同用途一个 HTTP 请求本质上就是客户端对服务器资源的一次操作。REST 风格把资源理解成名词把 HTTP 方法理解成动词。GET 对应“读取资源”POST 对应“创建资源或触发一个动作”但这个动作的结果不一定能被同一个 URL 重复拿到。举个例子你有一个/api/user/123的接口GET 它返回用户 123 的详细信息调用一百次结果都一样不改变服务器状态这就是安全连续多次调用每次效果一致这是幂等。而 POST 到/api/order每次调用都会创建一笔新订单返回的订单号每次都不一样这就是“非幂等、有副作用”。很多人会误以为 POST 只是在“提交表单”时用其实 POST 的定位要宽得多它可以是“创建资源”的入口也可以是“执行一个计算任务”的动作端点还可以是“上传文件”的通道。关键是服务器收到 POST 后一定会做点什么并且这个“做点什么”不应该被浏览器自动重复执行。这也是为什么浏览器刷新一个 POST 提交后的页面时会弹窗提示“是否重新提交表单”——浏览器天然知道 POST 是危险的。1.2 参数传递方式URL 与 Body 的边界GET 请求的参数通常放在 URL 的 query string 里形如?page1size20。POST 请求的参数可以放在 URL 上但更常见的是放在请求体 Request Body 里。这个边界的本质不是“哪个能放更多数据”而是参数是否属于资源定位的一部分。GET 的参数描述的是“我要哪个资源”比如页码、筛选条件、搜索关键字这些应当放进 URL因为服务端可以据此做缓存——同一个 URL 对应同一份数据CDN 和浏览器缓存都能生效。POST 的参数描述的是“我要往服务器里放什么数据”比如用户名、密码、文件内容这些应当放进 Body因为 URL 不能也不该承载这类结构化数据。你在实际项目中会发现一个典型的反模式用 POST 传分页参数。接口文档写着“POST /api/list”Body 里放page和size。这样做本身能跑通但你在日后排查问题时很痛苦不能通过 URL 直接复现请求不能随手分享给同事调试不能利用缓存。除非有不得已的原因比如参数太多、包含特殊字符分页查询、列表查询这类操作我强烈建议用 GET 语义。1.3 缓存、历史记录与幂等性GET 请求可以被浏览器、代理服务器、网关层层缓存这是它最大的性能优势。你在自己项目里做个简单的测试连续两次访问同一个 GET 接口如果响应头里有Cache-Control: max-age60第二次访问很可能直接命中浏览器缓存网络面板里显示from disk cache耗时 0ms。POST 几乎不会被任何中间层缓存因为语义上它代表“我要改变服务器状态”缓存一个写操作的结果是很危险的。历史记录也是 GET 的一个特性。浏览器地址栏会保存 GET 请求的完整 URL用户刷新、前进、后退时不需要重新提交表单。POST 的 URL 是固定的比如/api/order浏览器无法从 URL 反推出你创建了哪笔订单。所以在设计“可分享、可收藏、可回退”的页面链接时只能用 GET。这也是搜索引擎抓取页面时只发送 GET 请求的原因。幂等性最直接的影响是重试策略。前端偶尔会遇到网络抖动请求超时了你自动重试一次。如果这个请求是 GET第二遍发出去几乎不会有事如果是 POST可能就会造成重复下单。严谨的做法是给 POST 请求加上客户端生成的幂等键Idempotency-Key或者要求后端做重复订单校验。很多事故其实都源于“校验接口用了 POST超时重试导致了重复提交”而不是后端逻辑写错了。1.4 安全性误区POST 不等于加密“POST 比 GET 安全”是我听过最多的误解。实际上如果是裸 HTTP 协议GET 和 POST 都是明文传输抓包都能看到全部内容POST 唯一的“隐蔽性”只是在于参数不在 URL 地址栏里被直接看到但它依然会在浏览器开发者工具的 Network 面板里明晃晃地展示出来。真正影响安全性的是协议加密层HTTPS。它保护的是传输过程而不是请求方法。无论 GET、POST 还是 PUT走 HTTPS 都会加密整个请求头、请求体。所以不要再指望“把密码放在 POST Body 里就安全了”密码该脱敏脱敏请求该走 HTTPS 走 HTTPS审计日志里该打码打码这才叫安全设计。2. 其他请求方法PUT、DELETE、PATCH、OPTIONS、HEAD 的真实用途面试时候对方问“HTTP 请求方式有哪些”很多候选人能背出 GET、POST再往下就要想一会儿。其实完整清单是九个GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCH。这里面前五个在浏览器里能直接发出后三个有特殊用途。通常聊的重点集中在 PUT、DELETE、PATCH、OPTIONS 和 HEAD 上。2.1 PUT 与 PATCH全量替换与部分更新PUT 的语义是把一个资源完整地放到服务器指定位置。比如你要更新用户 123 的完整信息姓名、邮箱、手机号、头像你调PUT /api/user/123Body 里带上全部字段服务器拿到后直接整体替换。如果某个字段没传服务器就应该把该字段置为默认值或空值因为“全量替换”是 PUT 的约定。PATCH 的语义是部分更新。比如只改一个手机号你调PATCH /api/user/123Body 里只需要带{phone: 13800138000}服务器只更新这个字段其他字段保持不变。大量前端项目里其实只用了 POST 一个方法完成所有写操作接口文档写“POST /api/user/update”Body 里既可能传完整对象也可能只传部分字段语义完全取决于后端心情。这种设计在业务上能跑但会带来三个麻烦第一无法通过请求方法直接判断操作类型排查日志时只能读原始报文第二后端的路由规则也难做精细的权限控制比如只允许部分角色修改手机号在 POST 语义下你得在业务代码里再判断而在 REST 语义下你可以针对 PATCH 方法单独加权限逻辑第三客户端缓存、网关熔断、限流策略都很难基于方法做差异化配置。所以我建议新项目在定义接口时哪怕觉得麻烦也要把 PUT 和 PATCH 用起来至少把“全量更新”和“部分更新”区分开。2.2 DELETE删除也要讲究幂等DELETE 的语义是删除指定 URL 的资源它和 GET 一样是幂等的删除一个不存在的资源返回 404 也是正常的重复删除同一个资源第二次返回 404结果依然“资源不存在”不会报错。这一点在写重试逻辑时特别重要如果你调写了 DELETE 接口超时后重试是安全的不会造成额外副作用。但要注意有些后端工程师会把 DELETE 实现成“软删除”即逻辑上标记 deleted 字段为 true并不真正从数据库里抹掉数据。这种情况下重复 DELETE 依然幂等。如果后端把 DELETE 做成了“删除并触发一堆后续任务”每次删除还会发消息、扣库存、写审计日志那它就不再幂等了。前端是无法感知这些差异的所以最稳妥的做法是在删除操作前给用户一个确认弹窗并且在后端做好“可重入”处理保证同一个删除请求无论来多少次只有第一次真正执行业务逻辑。还有一个常见的问题是 DELETE 请求不能带 Body 吗规范上没有明确禁止但很多浏览器和中间层会丢弃 DELETE 的 Body或者把 DELETE 请求转换成 GET/POST 后内容丢失。你在开发时如果遇到 DELETE 需要传参数优先把参数放在 URL query 上比如DELETE /api/user/123?reasonduplicate而不是试图在 Body 里塞 JSON。实测中后端框架比如 Spring MVC 确实支持 DELETE 读 Body但网关、Nginx 层面有概率丢弃靠不依赖 Body 的做法最稳。2.3 OPTIONS 与预检请求跨域问题背后的机制OPTIONS 平时不起眼但一旦你的前端页面和后端 API 不在同一域名下你会在 Network 面板里看到大量OPTIONS请求这就是“预检请求”。浏览器会先发一个 OPTIONS 请求问服务器“我准备用 POST 带着 JSON 和自定义请求头X-Token来请求你允许吗”服务器用Access-Control-Allow-Methods和Access-Control-Allow-Headers回答“允许”浏览器才真正发出 POST。这个过程叫 CORS 预检目的就是防止恶意网站跨域发起危险操作。这个概念在前端面试里几乎是必考但很多人只是背答案“跨域会有预检请求”却不知道哪些请求会触发预检。简单说如果你用 fetch 或 axios 请求时条件满足下面任一条就会触发预检请求方法不是 GET、HEAD、POST或者 POST 的 Content-Type 不是application/x-www-form-urlencoded、multipart/form-data、text/plain之一请求头里包含了非简单请求头比如自定义的Authorization、X-Custom-Header在 XMLHttpRequest 上调用了upload.addEventListener()添加了事件监听这在实操中意味着你只要用Content-Type: application/json发 POST就必然产生预检请求。预检本身有一次额外的网络往返对弱网环境有明显影响尤其在移动端白屏等待的时间会拉长。优化的办法有两个一是让后端在预检请求的响应里加上Access-Control-Max-Age比如3600秒让浏览器缓存预检结果避免每次请求都发 OPTIONS二是如果接口简单、没有自定义头可以故意用text/plain或application/x-www-form-urlencoded作为 Content-Type绕开预检请求但这样你传递 JSON 数据就得手工序列化得不偿失。我更推荐第一种方案一劳永逸。2.4 HEAD、CONNECT、TRACE你用得少但面试常考的方法HEAD 和 GET 一样但服务器不返回响应体只返回响应头。它的用处是探路检查一个资源是否存在、大小有多大、是否支持 Range 断点续传或者只是检测链路是否通。浏览器里不会主动发 HEAD但很多静态资源检查工具、爬虫都在用它。前端开发时会遇到一个现象你用img标签请求图片时有些浏览器会先发一个 GET 请求而不是 HEAD这是因为浏览器内部对图片资源的探测逻辑不同不过这不影响我们理解 HEAD 的语义。CONNECT 是给代理服务器用的用来建立隧道最典型的场景是 HTTPS 通过代理访问TRACE 是回显请求让服务器把收到的报文原样返回用于调试。这两者在正常前端业务里几乎不会出现而且 TRACE 有安全风险容易引发 XST 攻击一般服务器都会关闭。面试时能说出这两个方法的名字再补一句“通常项目里用不到但它们是 HTTP 协议规范的组成部分”就已经超过大多数候选人了。3. 前端请求封装从 axios 到 fetch 的工程化实践前面讲了语义和原理接下来是落地层面。每个前端项目基本都要做一层请求封装不然每个页面都手写一套 XMLHttpRequest代码会乱成一锅粥。以我这几年的实战经验选型上最重要的抉择是到底用axios还是原生fetch以及怎么封装才不容易踩坑。3.1 为什么我推荐用 axios 而不用原生 fetchfetch 是浏览器原生的 API不用引入任何依赖看起来很美。但你在真实项目里跑起来就会遇到几个痛点第一个痛点是响应体解析。fetch 默认不会读 Body 内容你要拿到 JSON 必须手动res.json()且只能读一次一旦需要读取响应头的某种格式还要自己区分类型。axios 在这点上默认帮你做了 JSON 解析开箱即用。第二个痛点是超时控制。fetch 想要设置超时必须借助AbortController还要额外写监听逻辑。axios 直接配置timeout: 10000就完事超时会自动触发取消请求并抛出错误对开发者极其友好。第三个痛点是错误处理。fetch 在收到 404、500 时不会抛异常只有在网络层失败时才 rejectaxios 则默认会把非 2xx 状态码当作错误来 reject并且能把 “HTTP 状态码错误”和“网络错误”区分开配合拦截器做统一提示非常自然。我并不是说 fetch 就不能用它在编写独立的轻量工具、或者运行在极简环境时很合适但到了大型业务系统里axios 的拦截器、取消请求、响应拦截、进度回调这些能力能让你的代码少写一半。所以新项目我基本默认选 axios除非团队明确要求零依赖。3.2 统一封装拦截器、错误处理与超时控制封装请求层时最重要的两个环节是请求拦截和响应拦截。请求拦截器里通常干三件事加公共参数、加鉴权 token、做统一 headers 处理。响应拦截器里通常干三件事统一解包数据、统一处理错误码、统一触发登录跳转。给你一个我在项目里常用、并且实测稳定的 axios 封装雏形import axios from axios; const service axios.create({ baseURL: process.env.VUE_APP_API_BASE, timeout: 15000, withCredentials: true, }); // 请求拦截自动携带 token并附带请求标识 service.interceptors.request.use( (config) { const token localStorage.getItem(access_token); if (token) { config.headers[Authorization] Bearer ${token}; } config.headers[X-Request-Id] ${Date.now()}-${Math.random().toString(36).slice(2, 10)}; return config; }, (error) Promise.reject(error) ); // 响应拦截统一拆包、统一错误处理 service.interceptors.response.use( (response) { const res response.data; if (res.code ! 0) { // 业务错误统一提示 showToast(res.message || 请求失败); return Promise.reject(new Error(res.message)); } return res.data; }, (error) { if (error.code ECONNABORTED) { showToast(请求超时请稍后重试); } else if (error.response) { if (error.response.status 401) { showToast(登录已过期请重新登录); location.href /login; } else if (error.response.status 403) { showToast(您没有该操作权限); } else if (error.response.status 500) { showToast(服务器开小差了请稍后重试); } else { showToast(error.response.data?.message || 请求失败); } } else { showToast(网络连接异常请检查网络); } return Promise.reject(error); } ); export default service;这段代码有几个细节很容易被忽略我一一说明。withCredentials: true这一行很多人写成false或直接不写导致调试时发现跨域请求带 cookie 失败。只要你的系统用了 cookie 做登录态就必须开启它。开启后后端也要配合配置Access-Control-Allow-Credentials: true否则浏览器仍然会拒绝接收响应。X-Request-Id这个自定义请求头是联调时的救命稻草。每个请求带一个全局唯一的 ID后端把日志里打印出来排查“某个请求为什么慢了”“为什么报错了”时直接把请求 ID 甩给后端五分钟定位问题。没有它后端拿着一条日志找不到对应请求你在前端只能反复刷页面盲猜。超时处理我专门写了一个分支error.code ECONNABORTED。这个判断在 axios 里很关键因为超时和网络错误虽然都会走到 reject但错误对象的code字段不同。我是踩过坑的一开始没分开判断把超时也当成普通网络错误提示用户看到“网络连接异常”后去检查 Wi-Fi其实是服务器慢吞吞地超时了体验非常差。3.3 请求方式的编码细节GET 参数拼接、POST 的 Content-Type 选择封装完成之后还要解决“怎么正确传参”的问题。很多人用 GET 时直接在 url 里写模板字符串比如const res await request.get(/api/list?page${page}size${size});如果page或size是数字、字符串没问题但一旦参数里有特殊字符比如搜索关键字带或#URL 就会被截断后端收到一个残缺的查询字符串。所以正确的做法是传入params对象让 axios 帮你做 URL 序列化const res await request.get(/api/list, { params: { page: 1, size: 20, keyword: helloworld }, });axios 会使用内置的paramsSerializer对参数值进行编码helloworld会被转成hello%26world后端拿到后解析出来依然是原始字符串。POST 的 Content-Type 选择也是个大坑。最常见的有三种application/json用于传结构化对象后端用RequestBody接最简单直接。application/x-www-form-urlencoded用于表单提交参数格式是keyvaluekey2value2后端用RequestParam或表单对象接。multipart/form-data用于文件上传必须用这个类型才能传输二进制内容。实战中最容易出错的是用 axios 传application/x-www-form-urlencoded。如果你写qs.stringify(data)然后作为字符串传给 axiosaxios 会自动帮你设置 Content-Type 为application/x-www-form-urlencoded但如果你直接传对象axios 默认会用application/json后端如果按表单方式解析就得到一个“请求体为空或格式不对”的错误。所以一旦确定用表单上传就要像这样显式处理import qs from qs; const data { username: admin, password: 123456 }; const res await request.post(/api/login, qs.stringify(data));这里的qs.stringify会把{ username: admin, password: 123456 }转成usernameadminpassword123456axios 检测到字符串内容时就会自动设置Content-Type为application/x-www-form-urlencoded。如果你用的字段名比较复杂也可以手动指定const res await request.post(/api/login, data, { headers: { Content-Type: application/x-www-form-urlencoded }, transformRequest: [(value) qs.stringify(value)], });不过除非后端接口是历史遗留的表单接口我一般优先推荐 JSON 格式因为字段嵌套、数组、对象结构都能无损表达前端也不需要额外引入 qs 工具库。4. 日常开发中的请求方式坑位与排查路线理论讲完封装讲完真正让我觉得“这些知识值钱”的部分是那些你在文档上看不到、只有实际踩过才知道的坑。挑四个我印象最深的请求方式相关坑位按排查路线说清楚方便你下次直接复刻定位思路。4.1 跨域预检OPTIONS带来的“看不见的请求”场景是这样前端页面在https://app.example.com后端接口在https://api.example.com我用 axios 发了一个 POST 请求后端明明处理了但前端疯狂报CORS policy错误。打开 Network 面板发现请求列表里多了一个OPTIONS请求状态码是 200但紧跟的 POST 却被浏览器拦截了。排查路线第一步确认是不是预检请求被拦。看 OPTIONS 请求的响应头重点检查三样东西Access-Control-Allow-Origin是否为https://app.example.com或*注意带withCredentials时不能用*、Access-Control-Allow-Headers是否包含了你在请求头里写的Authorization和Content-Type、Access-Control-Allow-Methods是否包含POST。这三个条件任何一个不满足浏览器就会阻止真正的 POST 请求即使后端已经收到了预检请求并正常响应。第二步如果三个条件都满足但还是报错看看 OPTIONS 响应里有没有Access-Control-Allow-Credentials: true。只要你的前端开了withCredentials后端必须回这个头否则浏览器同样拦截。第三步确认预检缓存。如果你在 OPTIONS 响应里设置了Access-Control-Max-Age: 600那么 10 分钟内的同类型请求不会再触发预检。如果后端没设置那么每次请求都要多一次 OPTIONS 往返。在移动端弱网环境下这个往返可能吃掉几百毫秒甚至几秒。所以排查完兼容性问题后一定要顺手把 Max-Age 加上。4.2 405 与 403请求方法不被服务端允许前端的报错五花八门最典型的是当你对一个接口用了PUT或DELETE后端返回405 Method Not Allowed。很多前端遇到 405 第一反应是“接口地址写错了吧”但拦下报文看URL 是对的其实是后端的路由里没有注册这个 HTTP 方法。排查思路先用 Postman 或 curl 直接请求同一地址的 PUT/DELETE如果同样返回 405说明问题在后端如果后端能用那大概率是网关层或 Nginx 配置把 PUT/DELETE 方法给过滤了比如某些云厂商的 WAF 默认拦截 PUT/DELETE 请求。我遇到过更隐蔽的版本后端接口支持 PUT但请求头里带了Content-Type: application/json且方法为 PUT 时网关层会先返回 405 而不转发到后端因为 Nginx 配置里用的limit_except只放开了 GET 和 POST。这种排查需要看 Nginx 的access.log如果日志里根本没有这条 PUT 请求说明请求在到达后端之前就被挡了。解决办法通常是调整 Nginx 配置给对应 location 加上limit_except GET POST PUT DELETE { deny all; }或者直接开放全部方法。如果是 403而不是 405那一般是权限问题。服务端明确收到了请求但判断你没有权限调用这个 HTTP 方法。比如有些后端框架会按角色配置 method 级权限管理员可以用 DELETE普通用户只能用 GET。这个时候前端能做的只是根据状态码给出对应提示不要重复重试重试只会让后端防护日志刷屏。4.3 GET 请求参数过长导致的 414 问题服务端和浏览器对 URL 长度都有限制浏览器层面的下限一般是 2KB 到 8KB 不等但服务端常常会设置更小的限制。一旦你把大量参数拼在 GET 的 query string 里比如导出报表时带上几十个筛选字段URL 可能瞬间超过 8KB此时请求根本发不出去直接报 414。排查方法是我实战中最爱用的打开 Network直接复制那个失败的请求 URL粘贴到编辑器的左下角看字符数超过 4KB 就要警惕。然后判断这个接口是不是真的适合 GET如果参数是结构化筛选条件而且需要缓存那可以考虑把参数做一次压缩编码比如 gzip 后 base64但这样服务端也得配合解码如果参数列表是动态增删的字段数组那干脆改成 POST JSON反正它本质上是“查询条件的组合”放在 Body 里反而更清晰。另一种思路是拆请求把一次大查询拆成多个小查询比如先查询 ID 列表再按 ID 分批查询详情用Promise.all并发请求。这样既避免了 URL 过长又能利用浏览器同域名的并发连接数。不过要注意串行和并发的选择后面会在性能部分详细讲。4.4 缓存陷阱GET 请求结果不更新的问题GET 请求被浏览器默认缓存有时候你改了服务端数据回页面上重新请求同一个 GET 接口却发现返回的还是旧数据——这就是缓存造成的。排查路线先在 Network 面板看那条请求的 Size 列如果显示from disk cache或from memory cache说明根本没有发出去浏览器直接用缓存顶替了。应对办法有几种按推荐顺序排服务端设置正确的Cache-Control头比如no-cache意思是“每次使用前都去服务器确认但可以用缓存做条件请求”再配合ETag和Last-Modified让浏览器发一个If-None-Match请求服务器返回 304 时不用下载完整内容。如果服务端接口设计不合理没有设置任何缓存头前端可以主动给 URL 加上防缓存参数比如?_t${Date.now()}强制跳过缓存。这个方法简单粗暴但是要控制使用频率否则会让 CDN 缓存完全失效。更好的方式是在请求头里设置Cache-Control: no-cache因为浏览器对 fetch 和 axios 在默认情况下大部分遵循服务端响应头但这在当前项目里实测下来稳定性不够理想最终还是改后端响应头解决问题。我给你的最终建议是接口设计阶段就明确哪些 GET 接口允许缓存、哪些不允许。比如用户信息接口不允许缓存商品列表接口允许缓存 60 秒。这种分工越早定下来后面排缓存疑难杂症的时间越少。5. HTTP 连接复用与前端性能从 keep-alive 到 HTTP/2 多路复用聊请求方式很多人会忽略底层的连接管理但恰恰是这块决定了你的页面请求是快还是慢。前端看到的只是一个fetch调用背后浏览器和服务器之间要经历 DNS 解析、TCP 三次握手、TLS 握手、然后才是 HTTP 请求。如果每个请求都新建连接光握手的开销就能吃掉一两百毫秒。5.1 Connection: keep-alive 与请求合并HTTP/1.1 默认开启Connection: keep-alive意思是同一个 TCP 连接可以承载多个 HTTP 请求避免重复握手。浏览器对同一域名的并发连接上限在 HTTP/1.1 下通常是 6 个左右所以你会看到页面加载时很多请求排队等着空闲连接。在这种情况下前端能做的优化有两个。第一个是减少请求数量把多个小的请求合并成一个比如同一个页面需要用户信息、菜单信息、通知信息三个接口时可以用Promise.all并行发但更优的方案是后端提供一个聚合接口一次返回所有数据减少三次握手和请求头的开销。第二个是合理利用连接浏览器会自动复用 keep-alive 连接但如果你频繁切换域名比如把接口拆到三个不同子域浏览器要为每个域名单独建立连接反而更容易触发连接数瓶颈。实测下来同域的 GET 请求把keep-alive打开后连续发送 20 个请求握手次数只有最初一次耗时对比每个请求都重新建连的情况能快 3 倍以上。所以排查性能问题时先看 Network 面板底部有没有Connection: keep-alive响应头没有的话一定要让后端加上。5.2 HTTP/2 多路复用对请求方式的影响HTTP/2 用多路复用解决了 HTTP/1.1 的队头阻塞问题同一个连接内可以并行传输多个请求和响应请求不再需要排队等待空闲连接。这意味着你可以在一个连接里同时发送 GET、POST、PUT 多个请求连接数上限大幅提升甚至把一个页面的资源拆分到几十个小请求也不再像 HTTP/1.1 那样挤在 6 条连接里互相争抢。前端切到 HTTP/2 后我观察到一个很有意思的现象那些为了减少请求数而做的接口聚合反而变得不那么重要了。因为多路复用下每个请求的独立头占用成本变低大量小请求的并行能力更强。但要注意HTTP/2 依然有“请求优先级”的概念高优先级的 HTML 和首屏 CSS 优先传输低优先级的图片和统计请求让路。所以在配置资源加载时别把所有资源都设为最高优先级。服务端启用 HTTP/2 的前提是必须用 HTTPS。如果你在浏览器地址栏看到协议是http://那么 HTTP/2 大概率无法工作因为主流浏览器都要求h2必须走 TLS。这也是为什么我前面提到尽早把接口切到 HTTPS 上不只是为了安全还是为了性能。5.3 一个真实优化案例减少不必要的 GET 请求最后分享一个实际优化案例。某个后台管理系统列表页每次切换筛选条件都会触发一个 GET 请求请求地址是/api/list?page1size20status1。一次全量筛选操作要切换 5 个维度请求发了 5 次接口响应 200ms总耗时 1 秒。优化方案不是把请求改成 POST而是把“连续触发的筛选操作”做一个 300ms 的防抖只有用户停止操作后才发一次请求。然后在服务端加上Cache-Control: max-age5让五分钟内的相同筛选请求直接命中缓存整个列表切换过程从 1 秒降到 400ms。这个案例我拿出来说是想提醒你请求方式本身不是性能瓶颈的核心但请求的设计方式会直接影响你能不能用缓存、能不能做防抖、能不能做连接复用。用 GET 让缓存成为可能用分开的小请求让多路复用发挥作用用防抖加并发控制减少无效请求。这些动作组合在一起比单纯把代码从 POST 改成 GET 有效得多。对我个人来说最深的体会是不要迷信“用 POST 就高级”也不要觉得“GET 只能拿数据”。理解每个 HTTP 方法背后的语义把它当成一种表达意图的语言你的接口设计和前端封装都会清晰很多。下次再有人问你 GET 和 POST 的区别除了“查和改”希望你能说出语义、幂等、缓存、安全边界这些真正有价值的东西来。