form的method属性合法值只有get和post；前者将数据附加在URL后适用于非敏感查询，后者将数据放请求体中适用于敏感或大量数据提交。
form 的 method 属性值只有两个合法选项
method 是 <form></form> 标签的原生属性，浏览器只认 "get" 和 "post" 两种字符串值（大小写不敏感，但规范推荐小写）。其他如 "GET"、"Post" 或 "submit" 等写法虽可能被某些浏览器降级处理为 "get"，但属于未定义行为，不可依赖。
常见错误现象：后端收不到参数，或参数出现在 req.query 而不是 req.body，往往就是 method 拼错、漏写，或被 JS 动态修改时赋了非法值。
注意：method 不是开关，它不控制“是否发送数据”，而是明确告诉浏览器「用哪种 HTTP 方法封装这组表单字段」——这直接决定数据放哪儿、怎么编码、能否刷新重发。
GET 提交时，action URL 会被自动拼接查询参数
当 method="get" 时，浏览器会把所有成功控件（name 非空且未被 disabled）的 name=value 对，经 URL 编码后追加到 action 的末尾，用 ? 分隔，多个参数用 & 连接。例如：
立即学习“前端免费学习笔记（深入）”；
<form action="/search" method="get"> <input name="q" value="hello world"> <input name="page" value="2"> </form>
提交后实际请求地址是：/search?q=hello%20world&page=2。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
关键点：
-
enctype对 GET 完全无效，浏览器会忽略它；<input type="file">在 GET 表单中不会被序列化，字段直接丢弃 - 如果
action已带查询参数（如action="/search?src=form"），新参数会追加在后面，变成/search?src=form&q=... - 服务器必须从 query string 解析参数（如 Express 的
req.query），而非请求体
POST 提交时，enctype 决定数据如何编码进请求体
method="post" 本身不指定编码方式，真正起作用的是 enctype 属性，默认值为 "application/x-www-form-urlencoded"。它和 method 是绑定生效的组合：
- 普通文本字段（
text、select等）：默认编码下，数据以key1=value1&key2=value2形式放进请求体，服务端需解析req.body - 含文件上传：必须显式设置
enctype="multipart/form-data"，否则后端只能收到文件名字符串，拿不到二进制内容 -
enctype="text/plain"极少用，仅用于调试，字段间换行分隔，不编码空格和特殊字符，服务端难以可靠解析
常见坑：method="post" 却没设 enctype，又想传文件 → 后端 req.body 里只有空对象或乱码字符串；或者用了 enctype="multipart/form-data" 却没配好后端 multipart 解析中间件（如 Express 的 multer）。
刷新页面时，GET 和 POST 的行为差异直接影响用户操作
这是前端最易感知、也最容易引发 bug 的区别：
- GET 请求可被浏览器缓存、收藏、分享；刷新只是重发一次查询，不会重复创建资源（幂等）
- POST 请求不缓存；刷新会弹出“重新提交表单”提示（Chrome/Firefox），若用户确认，就真的再 POST 一次 —— 可能导致重复下单、双评论、库存多扣
所以不能只看“要不要加密”，而要看语义：搜索、筛选、查看详情 → 用 GET；登录、发帖、支付回调 → 必须用 POST（或更精确的 PUT/DELETE）。哪怕你把密码 POST 过去，只要这个动作本质是“查用户信息”，也违背了 HTTP 语义，后续 CDN、日志分析、前端路由复用都会出问题。
真正容易被忽略的点：很多团队用 POST 实现搜索，只为“隐藏参数”，结果发现 SSR 渲染失败、PWA 离线缓存失效、SEO 抓取不到结果页 —— 因为搜索引擎只爬 GET URL，不触发 POST 表单。
