表单提交时method和action必须与后端路由及请求方法严格匹配，否则返回405错误；GET适合简单查询，POST用于敏感或大数据；name属性是后端取值唯一依据，disabled控件不提交，enctype决定解析方式，调试应优先查看Network中的真实请求。
表单提交时 method 和 action 必须匹配后端路由与接收方式
浏览器只管把数据按 method（GET 或 POST）发到 action 指定的 URL，后端能不能收到，取决于你写的接口是否监听了对应路径和方法。常见错误是前端写 <form method="POST" action="/login">，但后端只写了 GET /login 路由，结果 405 Method Not Allowed。
实操建议：
-
GET提交的数据会拼在 URL 后（如/search?q=abc），适合简单查询；敏感或大体积数据必须用POST -
action值为空字符串（action=""）表示提交给当前页面 URL，方便调试 - Node.js + Express 中，需显式启用
body-parser（或 Express 4.16+ 的内置express.json()和express.urlencoded()）才能解析POST表单体 - Python Flask 默认能直接读
request.form，但若前端用了enctype="multipart/form-data"（比如上传文件），就得额外处理
input 的 name 属性是后端取值的唯一依据
后端收不到字段？90% 是因为漏写了 name。浏览器只把带 name 的控件（input、select、textarea）的值打包发送，id 或 class 完全不影响提交内容。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
-
<input type="checkbox" name="hobby">如果没勾选，这个字段根本不会出现在请求中 —— 后端不能假设它存在，得做空值判断 - 多个同名
checkbox（如name="hobby"）会以数组形式提交（如hobby=reading&hobby=coding），后端需按数组解析，不是只取第一个 -
disabled的控件不参与提交，要用readonly替代（如果只是禁止编辑但需要传值） - 中文
name值（如name="用户名"）虽能提交，但增加后端解析负担，不推荐
后端接收时注意 Content-Type 对应的解析逻辑
表单默认提交的 Content-Type 是 application/x-www-form-urlencoded，这是最常见也最稳妥的方式。但一旦改了 enctype，后端就得换解析方式：
-
enctype="application/x-www-form-urlencoded"（默认）：字段按 key=value 编码，空格变+，中文转 %xx，后端通常自动解码 -
enctype="multipart/form-data"：用于文件上传，每个字段变成独立 part，必须用专门的 multipart 解析器（如 Express 的multer、Flask 的request.files） -
enctype="text/plain"：几乎没人用，字段值不编码，空格保留，后端需手动拆分解析，兼容性差 - 用 JavaScript 手动
fetch提交时，若设了headers: {'Content-Type': 'application/json'}，那后端就不能再读form，得从原始 body 解 JSON
调试时优先检查浏览器开发者工具的 Network 标签页
别猜，直接看真实发出的请求长什么样。在 Network 里点开刚提交的请求，重点看三块：
-
Headers 里的
Request Method和Content-Type是否符合预期 - Form Data（或 Query Params）标签页，确认字段名、值、是否被截断或乱码
- Response 状态码：400 说明后端解析失败（比如 JSON 格式错），404 是路由没配对，500 是后端代码抛异常
- 如果 Form Data 为空，大概率是前端没写
name，或用了disabled，或 JS 阻止了默认提交但没手动发请求
复杂点在于：表单本身很简单，但前后端约定稍有偏差（比如字段名大小写、嵌套结构、空值处理逻辑），就会导致“看起来提交了，后端却收不到”。盯住 Network 里的原始数据，比翻十遍代码都快。
