GET请求URL长度实际受限于浏览器和服务端双重限制：IE硬截2083字符，Chrome/Firefox虽宽松但Nginx默认4KB header缓冲会触发400错误，且PHP的max_input_vars默认1000参数易导致静默丢弃。
GET 请求 URL 长度实际卡在哪？
不是“理论上2048字符”，而是浏览器和服务端双重掐脖子。IE硬性截断在 2083 字符，Chrome/Firefox 虽宽松些，但一旦超 8192 字符，Nginx 默认会直接 400 Bad Request（除非改 large_client_header_buffers）。更现实的是：PHP 的 max_input_vars（默认1000）会在参数过多时静默丢弃后半部分，$_GET 看起来“没报错”，但字段莫名消失。
- 别拼接长 JSON 字符串进 GET——URL 编码后体积翻倍，极易触顶
- 搜索场景带多个筛选条件（如
?category=tech&tag=js&tag=css&sort=date&offset=100），字段一多就危险 - 用
encodeURIComponent()包裹每个值，但别指望它能救超长 URL
POST 的“无限制”其实是假象
POST 数据不走 URL，但服务端配置才是真瓶颈。PHP 默认 post_max_size=8M，超出直接返回空 $_POST 和 $_FILES；Node.js 的 Express 若没配 app.use(express.json({ limit: '10mb' })) 和 app.use(express.urlencoded({ limit: '10mb', extended: true }))，大 body 会直接让 req.body 为 {}；Nginx 更狠，client_max_body_size 默认常是 1m，上传文件超 1MB 就 413。
- 文件上传必须设
enctype="multipart/form-data"，否则<input type="file">提交后后端收不到二进制内容 - 同一表单混用文本字段和文件时，
multipart格式体积比application/x-www-form-urlencoded大 10%–20%，别忽略这个膨胀系数 - 前端发
fetch时若手动设Content-Type: application/json，后端必须显式调用express.json()，否则req.body永远为空对象
后端取参不匹配，数据就“消失”了
GET 参数永远只在 URL 查询字符串里，POST 数据永远只在请求体里，框架不会自动桥接。Express 中写 req.query.id 却用 POST 提交 id=123，结果就是 undefined；PHP 里用 $_POST['name'] 却发 GET 请求，照样拿不到。
- 原生
<form method="get"></form>提交后，后端只能从req.query（Express）、request.args（Flask）、$_GET（PHP）读 -
<form method="post" enctype="application/x-www-form-urlencoded"></form>→ 后端走req.body/request.form/$_POST -
<form method="post" enctype="multipart/form-data"></form>→ 必须用multer（Express）、request.files（Flask）、$_FILES（PHP），req.body里只有文本字段，且格式不同
缓存和幂等性不是性能问题，是逻辑陷阱
GET 请求被 CDN、浏览器、代理缓存是常态，用户点两次“搜索按钮”，第二次可能根本没发请求；而 POST 刷新页面会弹出“重复提交”警告，但用户仍可能连点两下，导致订单创建两次、积分扣两次。这不是代码写得不够快，是 HTTP 语义本身决定的。
立即学习“前端免费学习笔记（深入）”；
- 纯查询接口（列表、详情、搜索）必须用 GET，否则前端路由复用、服务端日志分析、CDN 缓存策略全乱套
- 涉及状态变更的操作（登录、下单、修改）必须用 POST（或更精确的 PUT/DELETE），且前端要加防重提交（如按钮置灰 + token 校验）
- 误用 POST 实现搜索，后端无法区分“新搜索”和“缓存命中”，也无法生成可分享的链接
client_max_body_size、PHP 的 post_max_size、Express 中漏掉的 express.json() 中间件，以及你忘了 enctype 这个属性。 
