HTML表单method属性仅支持get和post，无法直接使用PUT/DELETE；浏览器会将非法值静默降级为get或post，必须用fetch等JS方案手动发起RESTful请求。
HTML <form> 的 method 属性只能设为 get 或 post，它**无法直接映射到 RESTful 的 PUT、DELETE 等 HTTP 谓词**。这是浏览器原生限制，不是你写错了——所有现代浏览器都只支持这两种提交方式。
为什么 form method 不能用 put/delete？
HTML 规范（包括 HTML5）明确限定 <form method=""> 的合法值只有 get 和 post。即使你在代码里写 method="put"，浏览器也会忽略它，退回到默认的 get，或按实现差异静默转成 post（不可靠）。
这跟 RESTful 设计无关，是底层约束：表单提交本质是同步导航行为，而 PUT/DELETE 是语义化、幂等的操作，需要由 JavaScript 主动发起。
- 浏览器不解析
method="put"，控制台可能报 warning，但不会报错 -
formmethod属性（如<input type="submit" formmethod="delete">）同样只认get/post - 服务端收到的请求方法永远是
GET或POST，不可能是PUT或DELETE
想发 PUT/DELETE 请求，必须绕过 <form> 提交
真正符合 RESTful 的做法是放弃原生表单提交，改用 fetch() 或 XMLHttpRequest 手动构造请求。表单只负责收集数据，提交逻辑交给 JS。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
示例：一个“删除用户”按钮不该用 <form method="delete">，而应这样：
<button type="button" data-user-id="123" onclick="deleteUser(123)">删除</button>
<script>
function deleteUser(id) {
fetch(`/api/users/${id}`, { method: 'DELETE' })
.then(r => r.ok && location.reload());
}
</script>
- 避免在 URL 中拼接敏感 ID（如
?id=123）再用 GET 删除，这违反安全与幂等原则 - 如果必须用表单结构（比如带 CSRF token），可保留
<form>作为数据容器，但event.preventDefault()阻止提交，再用 JS 提取formData发送 PUT - 注意：CSRF 防护仍需存在，
fetch不会自动携带 cookie（除非配credentials: 'include'）
什么时候该坚持用 form method="post"？
当操作本质是「创建资源」且不需要幂等保证时，method="post" 就是正确选择——它天然对应 RESTful 的 POST 语义（非幂等、用于创建）。
例如用户注册、文章发布、上传文件（配合 enctype="multipart/form-data"）：
<form action="/api/posts" method="post"> <input name="title"> <textarea name="content"></textarea> <button type="submit">发布</button> </form>
- 服务器收到的是标准
POST /api/posts，body 含application/x-www-form-urlencoded数据，语义清晰 - 不要为了“看起来更 RESTful”强行用 JS 发 POST——原生表单更健壮、支持无 JS 回退、自动处理重定向和错误状态码
- 若后端要求 JSON body，就不能用原生
<form>，必须用 JS 序列化并设置Content-Type: application/json
真正容易被忽略的点是：RESTful 不是名词堆砌，而是对 HTTP 方法语义的尊重。浏览器表单只是工具之一，它的 method 属性不是 REST 的入口，而是历史兼容层。该用 JS 的地方别硬套 form，该用原生 post 的地方也别画蛇添足。
