form 的 method 属性仅控制浏览器提交数据时使用的 HTTP 方法（get 或 post），决定数据置于 URL 查询字符串还是请求体中，不涉及编码、验证或前端逻辑。
form 的 method 属性到底控制什么
它只决定浏览器用哪种 HTTP 方法把数据发给服务器，不涉及编码、验证或前端逻辑。填 method="get" 就走 URL 查询字符串，填 method="post" 就走请求体——就这么直接。
常见错误是把它和 action 混着改，结果 action 写错了 URL，method 却被当成“提交失败”的原因去排查。
-
method是属性名，get和post是它的值，不是属性本身 - 不写
method时浏览器默认用get，不是“没设置”，而是有隐式行为 -
method值大小写敏感：POST可以，但某些老旧代理可能不认Post
什么时候必须用 post 而不能用 get
不是“推荐用 post”，而是某些场景下 get 根本不可行，硬用会出错或被拦截。
- 表单里有
：必须配method="post"+enctype="multipart/form-data"，否则文件字段压根不发 - 密码、token、身份证号等字段：用
get会让这些值明文出现在浏览器地址栏、服务端 access log、代理缓存里 - 输入内容超长（比如大段文本、base64 图片）：
get受限于 URL 长度（通常 ≤ 2048 字符），超出部分直接被截断 - 操作有副作用（如创建订单、删用户）：HTTP 规范要求这类动作不该用
get，否则容易被爬虫或预加载误触发
get 和 post 在实际请求中差在哪
差别不在“安全”或“快慢”这种模糊说法，而在数据落点、可缓存性、以及服务端怎么收。
-
get的数据全在 URL 里：/search?q=js&sort=date，服务端从 query string 解析，前端能直接看到、复制、书签化 -
post的数据在 request body 里，URL 干净，但需要服务端明确读取 body（比如 Node.js 的req.body，PHP 的$_POST） -
get请求默认可被浏览器缓存、前进后退复用；post默认不缓存，每次都是新请求 - 浏览器对
get请求的重试更激进（比如网络中断后自动重发），而post重发会弹确认框
method 属性写错或漏写的典型表现
不是报错，而是行为诡异，容易让人往 JS 或后端逻辑上瞎查。
- 页面一提交就跳转到类似
http://localhost:3000/?username=abc&pwd=123的地址：大概率漏写了method，走默认get - 后端收不到任何字段，
req.body是空对象：前端用了post，但后端没配 body 解析中间件（如 Express 缺express.urlencoded()） - 表单点了没反应，控制台也无报错：检查是否误把
method写成methodt或拼错成mehod，属性名错就等于没设 - 上传文件后后端只收到文件名、收不到内容：
method="post"有了，但漏了enctype="multipart/form-data"
method 属性看着简单，但它和 action、enctype、后端接收逻辑是咬合在一起的，改一个就得同步核对其他三个地方。漏掉任意一环，表单就只是个好看的 HTML 结构。
