method="post"本身不提供安全性，仅将数据移至请求体；防泄露需https+服务端校验+csrf防护三者缺一不可，否则抓包仍可获取明文密码等敏感信息。
method="post"本身不提供安全性，它只把数据从 URL 移到请求体；真正防泄露要靠 HTTPS + 服务端校验 + CSRF 防护，缺一不可。
为什么只写 method="post" 还会被抓包看到密码
POST 只改变数据位置，不加密内容。如果 action 是 http:// 开头，Wireshark、Charles 等工具仍能直接读取明文请求体——包括密码、身份证号、token。浏览器地址栏没显示 ≠ 数据安全。
- 本地开发常用
http://localhost测试，容易误判“看不见就是安全” - 反向代理（如 Nginx）若配置了
log_format记录$request_body，且未过滤敏感字段，POST 数据照样进日志 - 前端用
fetch或XMLHttpRequest手动发 POST 请求时，method="post"属性完全不起作用
大数据量提交必须配对 enctype 和服务端解析能力
默认 enctype="application/x-www-form-urlencoded" 会把所有值转成 URL 编码字符串，适合文本，但上传文件或含二进制内容（如 Base64 图片、富文本中的 emoji+换行）时会出错或截断。
- 传文件必须显式写：
enctype="multipart/form-data"，否则后端收不到file字段 - 传 JSON 或原始二进制数据，要用
enctype="text/plain"或直接用fetch设置Content-Type，此时form原生提交不再适用 - Node.js 的
body-parser默认不解析multipart，需额外加multer；PHP 要检查upload_max_filesize和post_max_size配置
CSRF 和服务端 method 校验是绕不开的两道坎
攻击者可以伪造一个隐藏页面，用 JS 自动提交 POST 表单，method="post" 完全挡不住。所以：
- 所有敏感接口（登录、改密、支付）必须在服务端校验
req.method === 'POST'，不能只信前端 HTML 属性 - 必须嵌入一次性 CSRF Token：
<input type="hidden" name="csrf_token" value="abc123">，后端比对并立即失效 - 禁止用
<input type="hidden" name="role" value="admin">控制权限——这个值前端可任意修改
容易被忽略的编码与兼容性细节
中文、emoji、换行符在 POST 中不是“天然安全”的，乱码和截断常发生在编码链断裂时：
- HTML 表单要加
accept-charset="UTF-8"，否则旧版 IE 可能用 GBK 发包 - 后端接收时若没指定字符集（如 Java 的
request.setCharacterEncoding("UTF-8")），getParameter()会乱码 - 大段富文本提交时，GET 会因 URL 长度限制（通常 ≤2000 字符）直接 400 错误；POST 虽无理论长度限制，但 Nginx 默认
client_max_body_size 1m，超了返回 413
真正卡住人的从来不是 method="post" 这一行代码，而是 HTTPS 是否启用、CSRF Token 是否生成并验证、enctype 是否匹配后端解析器、以及日志中间件有没有偷偷打印 request.body —— 这些地方漏一个，前面全白做。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
