get请求url长度受限且需encodeuricomponent编码，敏感信息禁用；post大小受服务端限制，content-type决定后端解析方式；fetch中get禁带body，post须显式设body和headers；刷新时get安全，post需后端幂等设计防重提。
GET请求的URL长度限制和编码问题
浏览器对URL长度有硬性限制，不同环境差异大：Chrome约32768字符，IE仅2083字符，服务端（如Nginx默认4KB）也可能截断。一旦超限，GET请求会静默失败或返回414 URI Too Long。
所有参数都拼在URL里，必须经过encodeURIComponent()编码，否则空格、中文、斜杠等会导致路由解析错误或服务端乱码。常见坑是手动拼接字符串却忘了编码：url + '?name=' + name → 应为 url + '?name=' + encodeURIComponent(name)。
缓存和历史记录会完整保存带参URL，敏感信息（如token、密码）绝不能用GET传。
POST请求的body类型与后端解析强绑定
POST本身不限制数据大小，但实际受服务端配置制约：PHP默认post_max_size=8M，Node.js需手动设置body-parser限制，Nginx有client_max_body_size。超出直接返回413 Payload Too Large。
关键点在于Content-Type头决定后端如何解析body：
-
application/x-www-form-urlencoded：表单默认格式，参数像GET一样键值对编码，后端从req.body（Express）或$_POST（PHP）取值 -
multipart/form-data：文件上传必需，boundary分隔字段，后端需用multer（Node）或$_FILES（PHP）处理 -
application/json：前端需JSON.stringify(data)，后端必须显式解析JSON（如Express加app.use(express.json())），否则req.body为空对象
GET和POST在JavaScript fetch中的行为差异
很多人以为fetch(url, { method: 'POST' })自动发body，其实不设body选项时，POST请求仍会发出——只是body为空，且Content-Length: 0。这容易让后端误判为非法请求。
GET请求禁止带body（规范强制），即使写了body字段，浏览器也会忽略并清空，控制台可能报Failed to execute 'fetch': Request with GET/HEAD method cannot have body.。
实操建议：
- 用
GET只传简单过滤参数（?page=2&sort=name），避免嵌套对象或长文本 - 用
POST传复杂结构时，明确设置headers: {'Content-Type': 'application/json'}并确保body是字符串 - 调试时看Network面板的Headers → Request Method 和 Payload两栏，比猜更可靠
刷新/后退时GET安全而POST会重复提交
浏览器对GET请求天然幂等，刷新页面只是重发相同URL，无副作用；但POST刷新会弹出“确认重新提交表单”提示（Chrome/Firefox），用户点确定就真的再扣一次款、再发一封邮件。
这不是前端能完全拦截的逻辑——即使加event.preventDefault()，用户从地址栏回车或点击历史记录，照样触发原POST。真正防重提得靠后端方案：token校验、redirect-after-post（303跳转）、或接口层面做幂等设计（如用idempotency-key头）。
所以表单提交后，别停留在结果页，用res.redirect(303, '/success')或前端location.href = '/success'跳走，这是最轻量也最有效的规避手段。
真正难处理的是异步POST失败后的重试逻辑——按钮禁用状态、loading遮罩、错误提示位置，这些细节比方法选择更容易导致用户困惑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
