表单method属性写错、漏写或与后端取参方式不匹配是80%以上“收不到参数”问题的根源；它决定数据存放位置（req.query或req.body），必须严格匹配大小写和后端解析逻辑。
表单 method 属性写错、漏写，或和后端取参方式不匹配，是 80% 以上「收不到参数」问题的根源。它不是风格选择，而是前后端通信协议的硬性约定——写对了，数据才进对的地方。
为什么后端 req.body 是空对象？
常见现象：表单提交后，Express 的 req.body 是 {}，但 req.query 里却有值；或者反过来，req.query 为空，req.body 却没拿到字段。
- 最可能原因：
method写成了"GET"（大写）或"post"（小写混用），浏览器降级为"get"，但你后端在等req.body -
method="get"时，所有字段都会拼到 URL 查询串，后端必须从req.query读；method="post"才走请求体，依赖express.urlencoded()中间件解析 - 漏写
method属性，浏览器按默认行为用get，结果后端却写了req.body.xxx—— 这个空对象就注定出现
enctype 在 GET 表单里完全无效
如果你给 method="get" 的表单加了 enctype="multipart/form-data"，那它不会报错，但也不会起作用——浏览器直接忽略该属性，且 <input type="file"> 字段根本不会被序列化进 URL。
-
method="get"时，enctype被规范明确定义为“无意义”，任何值都无效 - 文件上传必须用
method="post"+enctype="multipart/form-data"，缺一不可 - 普通文本字段在
get下自动 URL 编码（空格→%20，中文→%E4%BD%A0），但若原始 value 含未编码的特殊字符（如&、=），会导致参数截断或解析错乱
刷新页面时，GET 和 POST 的行为差异会暴露设计缺陷
用户点浏览器刷新按钮，GET 请求会干净重发一次查询；POST 则大概率触发「确认重新提交」弹窗——但这不是保护，只是提醒。一旦用户点了“确定”，订单就可能下两次。
-
GET幂等：重复请求不会改变服务端状态，适合搜索、分页、详情查看 -
POST非幂等：重复提交可能创建多条记录、扣多次款、发多封邮件 - 仅靠前端禁用按钮不能防住刷新/前进后退/F5，真正可靠的方案是后端实现幂等性（如校验
idempotency-key或唯一业务 ID） - 更轻量的补救：成功提交后返回
303 See Other，让浏览器用GET跳转到结果页（Post-Redirect-Get 模式）
action URL 带查询参数时，GET 会覆盖还是追加？
别猜。浏览器的行为是确定的：它会把表单字段全部拼成新的 query string，并用 & 追加到 action 原有 URL 之后，不管原来有没有 ?。
- 例如：
action="/user/edit?id=123"+method="get"+ 字段name="name" value="Alice"→ 实际请求地址是/user/edit?id=123&name=Alice - 但如果后端框架（如 Express）只解析最终 query，那么
req.query.id取到的是123，req.query.name是Alice，看似没问题；换成method="post"，id=123就彻底消失——它既不在req.query，也不在req.body，除非你手动从 URL 解析 - 所以，带动态 ID 的表单，如果要用
POST，ID 应作为隐藏字段写进表单，而不是塞在action里
最容易被忽略的不是语法，而是「参数来源」这个隐含契约：method 决定了数据物理上在哪，而前后端是否按同一套规则去拿，才是表单能否跑通的关键。一个 method 拼写错误，就能让整个请求链路断在第一跳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
