form标签是提交协议声明器，定义action+method+enctype三元组规则；浏览器原生序列化依赖name属性和enctype编码方式，空值照常提交；手动序列化仅在需过滤字段、合并表单、校验文件或用fetch/axios时必需。
form 标签不是容器，是提交协议声明器
它不只“包住输入框”，而是向浏览器明确声明：接下来这些字段要按 action + method + enctype 三元组定义的规则打包、编码、发送。漏掉任一属性，浏览器就按默认逻辑走——而默认逻辑（比如 method="get"、action=""、enctype="application/x-www-form-urlencoded"）往往和后端接口不匹配。
表单序列化不是 JS 行为，是浏览器原生机制
当你点 <input type="submit">，浏览器会自动做三件事：
- 收集所有带
name属性且未被disabled的控件值（type="hidden"、<select>、<textarea>全算） - 按
enctype指定方式编码：application/x-www-form-urlencoded把键值对拼成a=1&b=2；multipart/form-data则用 boundary 分隔字段，每个字段单独编码（文件内容不转义，文本字段也不 URL 编码） - 把编码结果塞进 HTTP 请求体（
POST）或 URL 查询参数（GET），发给action地址
注意：id 不参与提交，name 才是字段身份标识；空字符串、undefined、null 值都会被当真实值提交（后端需自行判空）。
常见踩坑：序列化结果和你看到的完全不一致
现象举例：
立即学习“前端免费学习笔记（深入）”；
-
<input name="user" value="张三&李四">在application/x-www-form-urlencoded下实际提交为user=%E5%BC%A0%E4%B8%89%26%E6%9D%8E%E5%9B%9B（& 被编码），但若误设enctype="text/plain"，就会变成user=张三&李四（& 不转义，后端解析直接断开） -
<input type="checkbox" name="hobby" value="read">未勾选时，该字段根本不会出现在序列化结果里；勾选多个同名 checkbox，后端收到的是重复键（如hobby=read&hobby=swim），不是数组 - 含中文路径的
action="./api/submit"在子页面/user/edit下会拼出/user/api/submit，404 但控制台不报错，只显示“Failed to load resource”
什么时候必须手动序列化？
浏览器原生序列化够用，但以下情况必须绕过它：
- 需要过滤/重命名字段（比如去掉
confirm_password字段再提交） - 要合并多个表单或混入 JS 计算值（如时间戳、token）
- 上传前校验文件大小/类型，失败时不触发 submit 事件
- 使用
fetch或axios发送，而非跳转式提交（此时需用FormData构造对象，且传文件必须用它）
关键区别：FormData 对象会忠实复现原生序列化逻辑（包括 enctype="multipart/form-data" 的分段格式），但 URLSearchParams 只适用于 x-www-form-urlencoded 场景，且不支持文件。
