表单提交失败是因协议限制、请求头缺失、编码错配及框架劫持多重叠加所致；应先抓包确认请求发出，再比对请求头与body，最后检查前端绑定逻辑是否被覆盖。
表单提交后页面没反应或报错 net::ERR_CONNECTION_REFUSED
这是混合开发中极常见的现象，本质是 WebView 加载了本地 HTML5 页面（如 file:///android_asset/index.html），但表单却试图提交到远程 HTTP/HTTPS 接口。Android 9+ 和 iOS WKWebView 默认禁止 file:// 协议发起跨域请求，连同 HTTP 请求也会被拦截——哪怕目标接口本身可访问。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 检查
form的action属性是否为http://开头；如果是，必须改用https://（HTTP 在现代 WebView 中基本被拒） - Android 端若确需调试 HTTP 接口，可在
AndroidManifest.xml的android:usesCleartextTraffic="true"（仅限调试，上线前必须移除） - iOS 需在
Info.plist中配置NSAppTransportSecurity允许特定域名，不能全局放开
XMLHttpRequest 或 fetch 提交返回 403 或空响应
很多 H5 转 APP 工具（如 Cordova、Capacitor、uni-app）会在 WebView 启动时注入自定义 User-Agent 或移除 Referer，导致服务端风控策略拦截。尤其当后端校验 Referer、User-Agent 或要求携带特定 header（如 X-Requested-With）时，原生 WebView 默认不发这些字段。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用抓包工具（如 Charles、mitmproxy）确认请求发出时是否带
Referer；若为空，说明是file://加载导致，服务端不应依赖该字段做校验 - 前端主动补全关键 header：
fetch(url, { headers: { 'X-Requested-With': 'XMLHttpRequest' } }) - 后端避免强校验
User-Agent或Referer，改用 token 或签名机制验证请求合法性
表单提交后数据丢失或乱码（中文变 %E4%BD%A0%E5%A5%BD）
根本原因常是编码不一致：HTML 页面声明了 UTF-8，但表单未显式设置 accept-charset="UTF-8"，或后端接收时未按 UTF-8 解码。更隐蔽的是，某些安卓低版本 WebView 对 GET 参数中的中文编码处理异常，POST body 反而更稳定。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有
form标签加上accept-charset="UTF-8"，例如： - 避免用
GET提交含中文的表单，强制使用method="POST" - 后端接收时明确指定字符集，如 Node.js 的
body-parser需配encoding: 'utf8'，PHP 的mb_internal_encoding('UTF-8')
Cordova/uni-app 中 submit 事件未触发或被拦截
部分跨平台框架会重写表单默认行为，比如 uni-app 的 组件在非 H5 平台实际是模拟实现，不触发原生 submit 事件；Cordova 某些插件（如 keyboard 插件）也可能监听并阻止表单提交。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
的默认提交，改用@submit.prevent（Vue）或event.preventDefault()+ 手动fetch - 检查是否有插件监听了
keydown或touchend并调用了event.stopPropagation() - 在真机上用 Chrome DevTools 远程调试 WebView，断点查看
form.onsubmit是否绑定成功、是否被覆盖
