你点一下网页上的「提交订单」按钮，几秒后页面跳转、数据到账——这背后不是魔法，而是一套清晰的客户端请求处理流程。搞懂它，调试报错不抓瞎，写前端心里更有底。
请求不是凭空飞出去的
浏览器里所有「发请求」的动作，比如 fetch()、XMLHttpRequest、表单提交、甚至图片加载，本质都是向服务器发起一次 HTTP 请求。但注意：客户端（比如你的 Chrome）不会直接把「我要查余额」这种人话发过去，它得先打包成服务器能看懂的格式。
举个例子：
你用 JS 写了这么一段：
fetch('/api/user/balance', {
method: 'GET',
headers: { 'Authorization': 'Bearer abc123' }
});浏览器收到后，会组装成标准 HTTP 报文，包含请求行（GET /api/user/balance HTTP/1.1）、头信息（带认证 token）、空行，然后通过 TCP 连接发给服务器。
请求发出前，客户端悄悄做了三件事
第一，检查同源策略：如果目标地址是 https://bank.com/api/，而当前页面是 https://hacker-site.com，浏览器直接拦下——这是安全底线，不是后端能绕过的。
第二，自动加 Cookie：只要域名和路径匹配，且 Cookie 没过期、没设 HttpOnly 或 SameSite=Strict，浏览器就会默默把它塞进请求头里。你不用手写，但它真在。
第三，缓存判断：如果这个 URL 刚刚请求过，且响应头写着 Cache-Control: max-age=300，浏览器可能直接从内存或磁盘读旧数据，连网都不用上。
响应回来后，客户端怎么“拆包裹”？
服务器返回的响应也是一串结构化数据：状态码（如 200、404、500）、响应头（Content-Type: application/json）、空行、再加响应体（比如 {"balance": 8640}）。
这时候 JS 的处理逻辑就起作用了：
fetch('/api/user/balance')
.then(res => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json(); // 注意：这里才真正解析 JSON
})
.then(data => console.log('余额：', data.balance))
.catch(err => alert('加载失败，请重试'));很多人卡在 res.json() 这一步——它不是立刻执行的，而是返回一个 Promise，等浏览器把响应体流完整读完、校验 UTF-8 编码、再转成 JS 对象。如果后端返回的是乱码或半截 JSON，这里就会报错。
真实场景：为什么「点两次提交」会重复下单？
很多老系统没做防重，用户一着急连点两下「确认支付」，浏览器就发了两个几乎一样的 POST 请求。客户端本身不会判断「上一个还没回呢，这次先别发」——除非你手动加锁：
let isSubmitting = false;
function handleSubmit() {
if (isSubmitting) return;
isSubmitting = true;
fetch('/api/pay', { method: 'POST' })
.finally(() => isSubmitting = false);
}这就是客户端请求处理中最容易被忽略的一环：控制权始终在你写的 JS 手里，浏览器只负责「传话」，不管「有没有意义」。
下次看到控制台 Network 标签页里密密麻麻的请求，别只盯着红叉叉——点开一个，看看 Request Headers 是不是少了 token，Response 是不是返回了 HTML 而不是 JSON，Status 是不是 302 跳转到了登录页……这些细节，全藏在客户端请求处理的每一步里。