非主流浏览器需放弃原生支持假设，全程兜底：检测 type 是否生效须用 createElement 测试；polyfill 后需重绑事件；required/pattern 需手动校验并加 ^$ 锚点；disabled 元素提交前应移除 name；表单必须声明 accept-charset="UTF-8" 且文档为 UTF-8 无 BOM。
非主流浏览器（如旧版 IE、低版本 Safari、某些 WebView 内核）对 HTML 表单的支持不是“修一两个属性就能好”，而是必须放弃“它该原生支持”的假设，转为“它大概率不支持，我得兜住所有环节”。
检测 type 属性是否被真正识别
很多开发者以为 type="email" 或 type="date" 写上去就生效了，其实老浏览器会静默 fallback 到 type="text"，连 DOM 属性值都变不了——input.type 读出来还是 "text"，根本没触发校验逻辑。
- 正确检测方式：
const el = document.createElement('input'); el.type = 'date'; if (el.type === 'date') { /* 支持 */ }，不能靠'date' in el.attributes或 UA 字符串 - IE9–10、iOS Safari ≤15.6、Android WebView ≤4.4 都会失败，此时必须加载 polyfill（如 flatpickr 仅用于 date，不要用全量 webshim）
- polyfill 后 DOM 结构通常改变（比如生成 wrapper div），原来绑定在
input[type=date]上的事件监听器全部失效，得等 polyfill 初始化完成后再重绑（例如监听flatpickrInstance.loaded）
required 和 pattern 校验必须手动补全
IE9–10 认得 required 属性，但既不显示红边框，也不弹提示，form.checkValidity() 返回 false，invalid 事件却不触发——用户点提交，页面卡住，控制台安静得可怕。
- 必须在
form.addEventListener('submit', e => {...})中主动调用checkValidity()，再遍历每个required字段检查el.value.trim() === '' -
pattern在 Safari 旧版和部分 WebView 中不生效，且正则必须显式加^$锚点（pattern="[a-z]{3}"不行，得写pattern="^[a-z]{3}$"） - 服务端必须二次校验：前端 pattern 只是体验层，后端绝不信任任何客户端输入
disabled 元素在 Firefox 中仍可能被提交
标准规定 disabled 的表单控件**不会被提交**，但 Firefox 某些版本（尤其是配合 fieldset disabled 或 JS 动态设 disabled）会出现误提交，Chrome/Safari 却表现正常——这会让后端收到意外字段，引发逻辑错误。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 最稳妥做法：提交前遍历所有
disabled元素，临时移除其name属性：el.removeAttribute('name') - 如果要用
fieldset disabled，注意它内部所有子控件都会被禁用，但个别旧版 Firefox 对input的disabled状态读取不准，建议改用fieldset+ CSSpointer-events: none+ JS 阻止交互，再手动控制 name - 别依赖
el.disabled做条件判断——某些 WebView 下该属性存在但始终为false，应结合el.hasAttribute('disabled')
编码与字符集错位导致提交中断
Chrome 控制台报错 A form was submitted with a non-UTF-8 encoding，不是前端乱码那么简单，而是表单提交时用了 ISO-8859-1 编码，遇到 emoji 或中文就截断或发空值，Safari 和 Firefox 有时更沉默，直接丢数据。
- 必须在
<form>标签上显式声明：accept-charset="UTF-8" - HTML 文档本身也要确保 UTF-8：HTTP 响应头含
Content-Type: text/html; charset=UTF-8，且<head>里有<meta charset="UTF-8">（不要用<meta http-equiv="Content-Type">，某些旧内核不认） - 特别注意 BOM：文件保存为 UTF-8 无 BOM 格式，否则 IE/Edge Legacy 会进 Quirks Mode，连
accept-charset都不解析
最容易被忽略的是：非主流浏览器往往不是“功能缺失”，而是“行为不一致+静默失败”。你得把每个表单字段的生命周期拆开看——创建、渲染、交互、校验、序列化、提交——每一步都要做能力检测和降级，而不是只在提交那一刻才想起来兜底。
