POST的核心优势是将数据移入请求体，避免URL明文暴露、日志留存和长度限制；它解决显性泄露而非传输加密问题，仍需HTTPS和敏感字段防护。
method="post" 的核心优势不是“绝对安全”，而是把数据从 URL 里摘出来，避免明文暴露、日志留存和长度截断——它解决的是“显性泄露”问题，不是“传输加密”问题。
为什么 POST 能规避 URL 日志泄露
服务器、反向代理（如 Nginx）、CDN、浏览器历史记录、Fiddler 或 Chrome DevTools 的 Network 标签页都会完整记录 GET 请求的完整 URL，包括所有参数。一旦表单用了 method="get"，像 login?user=admin&pass=123456 这种就会直接写进 access.log。
POST 把数据放进请求体（request body），URL 本身不带敏感参数，日志里只留下 POST /login 这样的路径，内容需额外解析原始报文才能看到。
- 常见错误：以为加了
method="post"就不用防 XSS 或 CSRF —— 实际上攻击者仍可通过伪造表单或 JS 发起 POST 请求 - 注意点：后端日志若主动记录
request body（比如用body-parser+ 自定义中间件打日志），那 POST 数据照样会落盘，必须人工过滤敏感字段
POST 如何绕过 URL 长度限制与编码陷阱
浏览器和服务器对 URL 长度都有隐式限制（通常 2000 字符左右），GET 表单一超就丢数据；而 POST 没这限制，适合传大段文本、Base64 图片、JSON 数组等。
立即学习“前端免费学习笔记（深入）”；
另外，GET 对非 ASCII 字符（如中文）依赖 URL 编码（%E4%BD%A0%E5%A5%BD），容易因服务端解码配置不一致导致乱码；POST 可通过 Content-Type: application/x-www-form-urlencoded; charset=utf-8 显式声明编码，兼容性更稳。
- 典型场景：富文本编辑器提交含 emoji 和换行的长评论，用 GET 会截断或 400 错误，POST 可完整送达
- 关键配置：HTML 表单需配
accept-charset="UTF-8"，否则旧版 IE 可能用系统默认编码发包
POST 不等于加密，别忽略 TLS 和敏感字段处理
HTTP 层面的 POST 仅改变数据位置，不提供加密。如果走的是 http://，抓包工具（Wireshark、Charles）仍可直接读取明文请求体。
真正防窃听靠的是 HTTPS（即 TLS 层加密），它让整个 HTTP 报文（含 method、headers、body）都变成密文。没开 HTTPS 的 POST 和 GET 一样裸奔。
- 易踩坑：本地开发用
http://localhost测试 POST 登录，误以为“密码没出现在地址栏就很安全” - 补充动作：密码类字段应在前端哈希（如
scrypt或bcrypt）后再 POST，避免后端日志/数据库存明文
最常被忽略的一点：method="post" 只是 HTTP 动词选择，它不自动绑定 CSRF Token、不阻止重复提交、不校验 referer，这些都得靠额外机制补全。光改 method 解决不了权限绕过或重放攻击。
