action属性必须填后端实际接收请求的完整路径，如"/api/orders"；填错会导致404、405或cors错误，且需与method属性配套使用。
表单的 action 属性到底填什么
填错 action 是表单不提交最常见原因——它不是“随便写个路径就行”，而是决定浏览器把数据发给谁的关键地址。填相对路径（比如 "/login"）时，实际请求的是当前域名下的该路径；填绝对 URL（比如 "https://api.example.com/submit"）则会跨域发送。如果后端接口是 /api/v1/user，但你写了 action="user"，那浏览器会拼成当前页面路径 + user，大概率 404。
常见错误现象：404 Not Found、405 Method Not Allowed（比如后端只接受 POST，但你没写 method，浏览器默认用 GET）、控制台报 Blocked by CORS policy（跨域但没配好）。
- 后端接口是 RESTful 风格？直接填完整路径，如
action="/api/orders" - 用前端路由（如 React Router）？别填
action="/submit"——这会触发真实跳转，应禁用默认提交并用fetch手动发 - 本地开发时后端跑在
http://localhost:3001，但页面是file://协议？action无效，必须起一个本地 server
method 和 action 必须配套看
action 决定发给谁，method 决定怎么发。两者不匹配，后端根本收不到数据。比如 Django 视图只处理 POST 请求，但表单漏写 method="post"，浏览器就用 GET 发，后端连 request body 都不读。
- 默认是
GET：所有字段变成 URL 查询参数，有长度限制，不能传文件，不安全（密码会暴露在地址栏） - 敏感操作或传文件？必须显式写
method="post"（大小写不敏感，但惯例小写） - 想发
PUT/DELETE？原生表单不支持，得用fetch或框架封装，action只是目标地址，不解决动词问题
表单提交前要不要验证 action 是否可访问
不能靠前端 JS 检查 action 地址是否“能打开”——浏览器不会预请求那个地址，而且跨域下 fetch 会直接被拦。真正有效的检查，是在后端返回响应后看状态码。
立即学习“前端免费学习笔记（深入）”；
更实际的做法是：确保 action 路径和后端路由定义完全一致（注意末尾斜杠），并让后端对空提交或非法字段返回明确错误（比如 400 Bad Request 带 JSON 错误信息），而不是静默失败。
- 前后端约定好接口文档，比前端猜
action可靠得多 - 开发时用浏览器 Network 面板看实际发出的请求 URL 和 method，比反复改
action更快定位问题 - Nginx/Apache 代理了后端？确认代理配置里转发路径和
action匹配，比如action="/api/login"对应 Nginx 的location /api/
使用 JavaScript 提交时 action 还重要吗
重要，但角色变了。如果你用 event.preventDefault() 阻止默认提交，再手动 fetch，那 action 属性本身不参与发送——但它仍是语义占位符，方便调试和 SSR 场景回退。万一 JS 失败，用户仍可原生提交。
容易忽略的点：用 fetch 时，URL 参数要自己拼，不能依赖表单的 action 自动解析。比如 action="/search?q=foo" 是 GET 行为，但你用 POST 提交，就得把 q=foo 放进 body，而不是拼到 URL 后面。
- 保留
action值作为 fetch 目标，比如fetch(form.action, { method: form.method || 'get', ... }) - 表单有
enctype="multipart/form-data"？JS 提交时得用FormData构造体，不能直接 JSON.stringify - CSRF token 在表单里？记得从
form元素中取值，别硬编码，否则 JS 提交时漏掉就 403
action 看似简单，但牵扯路由、代理、跨域、前后端约定、降级逻辑多个层面。最常出问题的，不是写错了字符，而是没意识到它和后端部署方式、前端路由模式、HTTP 方法三者绑在一起。 
