method属性仅控制http请求方法，不决定后端处理逻辑；必须小写（get/post），未声明时默认get；formmethod仅对submit按钮生效，不影响js提交；实际使用中常被fetch/axios绕过。
method 属性只控制 HTTP 请求方法，不决定后端如何处理
HTML 的 method 属性本质是告诉浏览器：用 GET 还是 POST 发起请求。它不参与服务器逻辑判断，也不自动改变后端接收方式——后端必须显式适配对应方法（比如 Node.js 的 req.method === 'POST'，PHP 的 $_POST vs $_GET）。
常见错误现象：method="post" 但后端仍读 $_GET 或 request.query，结果拿不到数据；或者前端写成 method="POST"（大写），部分旧浏览器直接降级为 get。
-
method值必须全小写：get/post，大小写敏感 - 未声明
method时，所有浏览器默认使用get - 仅影响请求封装形式：URL 查询参数（
get） or 请求体（post），不影响 action 地址本身
formmethod 能覆盖 form 的 method，但只对特定按钮生效
formmethod 是 HTML5 新增的覆盖机制，但它**只作用于 <button></button> 或 <input type="submit"> 元素**，且仅在点击该元素时临时替换整个表单的提交方式。
典型误用：<form method="post">
<input type="text"><button formmethod="get">搜索</button>
</form> —— 点击“搜索”会发 GET 请求，但其他 submit 按钮仍走 POST；如果把 formmethod 写在 <form></form> 标签上，浏览器直接忽略。
-
formmethod不支持put、delete等方法，仅限原生get/post - 它不改变表单默认行为，只影响当前触发提交的按钮
- 与 JavaScript 的
form.submit()无关——JS 提交不会触发formmethod逻辑
GET 和 POST 的实际边界比文档写的更模糊
很多人记“GET 用于查询，POST 用于修改”，但真实限制来自协议语义和基础设施：GET 请求会被浏览器缓存、保存在历史记录、可能被代理/CDN 预加载；POST 则默认不缓存、不预加载、有重试确认提示。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
容易踩的坑：
- 用
GET提交含空格或中文的值，没做encodeURIComponent，导致 URL 解析失败或服务端乱码 - 以为
POST绝对安全——其实没配 HTTPS 时，请求体照样明文传输 - 在
GET中传大量数据（如长 JSON 字符串），触发 Nginx 默认 4000 字符的 URI 长度限制，直接 414 错误
现代开发中，method 属性常被 JS 提交绕过
多数 SPA 或带校验的表单，实际会调用 event.preventDefault() + fetch() 或 axios 手动发请求，此时 method 属性完全失效——它只在原生表单提交（无 JS 干预、无 preventDefault）时起作用。
这意味着：如果你写了 <form method="post" onsubmit="return false"></form> 却没补 JS 发送逻辑，表单就彻底无法提交。
- 服务端不能只依赖
method做权限或流程判断，必须校验请求来源、token、CSRF 等 -
enctype属性（如multipart/form-data）和method是协同工作的，改method时别漏掉它 - 表单可访问性（a11y）依赖原生提交机制，纯 JS 提交需手动补全键盘回车、焦点管理等逻辑
真正容易被忽略的是：浏览器对 method 的兼容处理非常“宽容”，比如 IE 会把空值或非法值当 get，而 Chrome 可能静默忽略——这种差异在跨团队协作或遗留系统维护中，常常成为排查接口 405（Method Not Allowed）的盲点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
