表单是网页中收集用户输入的主要手段，而 method 属性控制着这些输入如何被提交到服务器。虽然 <form> 标签只支持 get 和 post 两种常用提交方式，但两者在参数位置、浏览器行为、缓存策略和安全性上差异很大。选错方式可能让密码暴露在地址栏，也可能让搜索页无法分享。下面从HTTP语义和实际表现两个层面拆解这个问题。

两种提交方式在HTTP协议中的定位

GET和POST最初的设计目标就有明显区别。GET用于获取资源，请求参数以查询字符串形式拼接在URL后面，服务器根据这些参数返回对应资源；POST用于提交数据给服务器处理，比如创建用户、发表评论、提交订单。HTTP规范将GET列为安全方法，意味着多次相同请求不应改变服务器状态；POST则不具备这种安全属性，每次提交都可能产生新的数据，甚至多次提交会创建多条记录。这种语义差异是选择method属性的第一层依据。

举例来说，一个商品列表页按价格排序，使用GET请求 /products?sort=price 是合理的，用户可以放心刷新、收藏、转发，浏览器前进后退也不会出现异常。而如果是下单操作，使用POST提交订单数据，每次提交都会创建新订单，浏览器在刷新时会提示是否重复提交，这正是因为POST被设计为可能产生副作用的方法。理解这层语义也能避免搜索引擎爬虫误提交数据，因为爬虫通常只发GET请求，不会主动触发POST表单。

参数位置、长度与浏览器行为的实际对比

GET的参数直接出现在URL的 ? 后面，键值对用 & 连接。比如一个搜索表单，用户输入“手机”后地址栏变成 /search?keyword=手机。这种形式的好处是结果页可以被收藏，甚至把链接发给别人也能看到相同内容。坏处是参数暴露无遗，不适合放身份证号、密码等敏感字段。另外不同浏览器和服务器对URL长度有不同限制，通常总长度在2KB到8KB之间，超出部分可能被截断或直接报错，因此不适合传递大段文本或文件内容。

POST把数据放在请求体中，不在URL中展示。表单提交后地址栏仍只显示action地址，不会带上参数。这对登录、注册、支付等场景非常必要。POST没有URL长度硬性限制，但服务器一般会配置请求体大小，比如Nginx默认上传限制1MB，PHP的 post_max_size 也会限制POST数据量。需要上传大文件时还要调整服务端配置，不能简单认为POST可以无限传数据。另外，刷新POST提交的页面时浏览器会弹窗提示是否重新提交，这是为了防止重复提交，但也带来用户体验上的不便，需要配合重定向解决。

下面一个GET表单示例，提交后URL会带上查询参数：

<form action="/search" method="get">
  <input type="text" name="keyword" placeholder="输入关键词">
  <button type="submit">搜索</button>
</form>

GET提交后请求行类似 GET /search?keyword=手机 HTTP/1.1，参数完全可见。

再来看POST表单，提交后地址栏不会显示用户名和密码：

<form action="/login" method="post">
  <input type="text" name="username" placeholder="用户名">
  <input type="password" name="password" placeholder="密码">
  <button type="submit">登录</button>
</form>

POST提交后请求体包含 username=xxx&password=xxx，地址栏保持 /login 不变，避免敏感字段直接出现在URL中。

缓存、日志与安全性误区

缓存行为是两者一个容易被忽略的差异。GET请求的响应可以被浏览器、CDN和代理服务器缓存，下次访问相同URL可能直接返回缓存内容，这对查询类请求是好事，但若在URL中夹带敏感信息，这些信息也会被缓存下来，清理起来很麻烦。POST默认不会被缓存，每次提交都会到达服务器，适合实时性要求高或结果不可复用的场景。从日志角度看，Web服务器通常记录请求行，其中包含完整URL，所以GET参数会留在访问日志中；POST请求体一般不记录，但应用层可能自己记录，所以不能单纯依赖POST保护敏感数据。

安全性方面需要澄清一个常见误区：POST并不比GET更安全。两者在HTTP明文传输下都是裸奔，参数都可能被中间人窃取。真正的传输安全必须依赖HTTPS。区别只是GET参数暴露在浏览器历史、服务器日志、Referer头等位置，POST参数不会出现在这些地方。但POST防范不了抓包，也不能替代加密。提交敏感信息至少要使用POST加HTTPS，并配合CSRF防护、输入校验等机制。如果把安全全部寄托在method属性上，迟早会出问题。

如何根据业务场景做出选择

查询类操作优先GET。包括搜索框、筛选器、分页、排序、报表查询等，这些操作不改变数据，结果可复现，使用GET让URL可分享、可收藏、可刷新，也方便配合浏览器前进后退。如果查询参数很长，比如几十个筛选条件，超过URL长度限制，可以改用POST，但这属于兼容性妥协，不是语义上的最佳选择。对于纯粹的数据读取，GET的语义最清晰。

写入类操作使用POST。登录、注册、修改密码、发表评论、下单、支付、上传文件等，这些操作会改变服务器状态或涉及敏感数据，必须用POST。文件上传只能用POST，因为GET无法处理二进制内容且长度太小。对于删除、修改等操作，在严格RESTful接口中会使用PUT、DELETE等HTTP方法，但HTML表单原生只支持GET和POST，所以很多Web框架通过隐藏字段 _method 来模拟这些动词，后端再根据该字段路由到相应的处理逻辑。

避免重复提交可以结合Post/Redirect/Get模式。用户提交POST后服务器返回302重定向到结果页，浏览器再发GET请求显示结果，这样刷新时只会重新GET结果页，不会再次提交表单。这个模式在支付、文章发布等场景中非常有效。另外在表单提交前可以用JavaScript进行客户端校验，但客户端校验只是辅助，服务端仍需校验，method选择不能替代安全校验。最终的选择原则可以归纳为：读操作走GET，写操作走POST，敏感字段必须走POST并上HTTPS，需要可分享可收藏的页面走GET，超长参数或大文件走POST。

• 查询、排序、筛选用GET；
• 登录、注册、修改、上传用POST；
• 敏感字段即使使用POST也要上HTTPS；
• 大文件或超长参数用POST；
• 需要可收藏可分享的页面用GET。