GET与POST本质区别在于数据位置：GET将参数拼在URL查询字符串，POST将数据放请求体。必须用POST的场景包括传敏感信息、文件上传、请求体超2KB、执行非幂等操作；GET适用于纯查询、需分享链接、只读无副作用接口。
GET 和 POST 的本质区别在哪
根本不是“安全不安全”或“能不能传中文”这种模糊说法。关键看浏览器和服务器怎么处理：GET 把所有数据拼进 URL 查询字符串（?key=value&foo=bar），而 POST 把数据放在 HTTP 请求体里，URL 保持干净。
什么情况下必须用 POST
以下场景不用 POST 会出错或违反规范：
- 提交包含敏感信息的表单（如密码、token），因为
GET会把它们暴露在浏览器历史、服务端日志、代理缓存中 - 上传文件——
<input type="file">必须配合method="POST"和enctype="multipart/form-data" - 请求体超过 2KB（虽然没硬性标准，但多数浏览器对 URL 长度限制在 2048 字符左右；超长
GET可能被截断或 414 错误） - 执行非幂等操作（如下单、删数据、发邮件），因为
GET请求可被浏览器预加载、代理缓存、刷新重发，导致重复提交
什么情况下可以放心用 GET
GET 不是“低端选项”，它有明确适用边界：
- 纯查询类操作：搜索、分页、筛选（如
/products?category=book&page=2） - 需要书签/分享链接的场景——用户复制 URL 就能复现结果
- 后端接口明确设计为只读、无副作用，且参数简单（全部 ASCII、无空格、无二进制）
- 前端做缓存控制时，
GET天然支持 HTTP 缓存头（Cache-Control、ETag）
注意：GET 提交中文会自动编码成 %E4%BD%A0%E5%A5%BD，只要前后端都遵循 UTF-8 解码就没事；问题常出在后端没正确设置 request.setCharacterEncoding("UTF-8")（Java）或没配 Accept-Charset（Nginx）。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“前端免费学习笔记（深入）”；
form 标签里 method 属性写错的典型表现
常见错误不是语法报错，而是行为异常：
- 写了
method="get"却想上传文件 → 表单提交后文件字段为空，request.getFile()或$_FILES拿不到数据 - 写了
method="post"但漏了enctype→ 文件上传失败，普通字段正常；如果含中文，可能乱码（因默认application/x-www-form-urlencoded不带字符集声明） - 用
GET提交长搜索词 → URL 被截断，后端收不到完整参数，日志里看到一堆...&q=xxx省略号 - 刷新一个
POST表单页面 → 浏览器弹“确认重新提交表单”，这是正确行为；如果没弹，大概率实际发的是GET
<form method="POST" enctype="multipart/form-data"> <input type="text" name="title"> <input type="file" name="cover"> <button type="submit">上传</button> </form>
这个例子里，method 和 enctype 缺一不可。少写 enctype，type="file" 就形同虚设。
真正容易被忽略的点是：前后端对 HTTP 方法语义的理解是否一致。比如前端用 GET 调用一个本该是 POST 的支付接口，可能测试环境不报错，但上线后被网关拦截、被审计系统告警——因为方法名背后是约定，不是技术限制。
