应使用 readonly 替代 disabled 以实现视觉禁用但保留提交功能；对不支持 readonly 的控件可用 pointer-events: none + tabindex="-1" 模拟，但服务端必须校验所有字段。
如何绕过 input 元素的 disabled 属性限制
禁用表单项后，input 不仅不可编辑，还会被浏览器忽略提交（即不会出现在 FormData 或表单序列化结果中）。如果你只是想“视觉上禁用但保留提交能力”，disabled 本身不支持这种行为——必须换方案。
用 readonly 替代 disabled 的适用场景
readonly 让用户无法编辑内容，但元素仍可聚焦、可选中、会随表单一起提交。这是最常用且安全的替代方式，尤其适用于只读展示型字段（如订单编号、生成的时间戳）。
-
readonly对<input type="text">、<input type="number">、<textarea></textarea>有效；对checkbox、radio、select无效 - 需配合 CSS 避免误导用户，例如加
background-color: #f5f5f5;和cursor: not-allowed; - 注意：JavaScript 仍可修改
value，readonly仅限制用户输入，不提供数据保护
用 pointer-events: none + tabindex="-1" 模拟禁用外观
当必须保留 disabled 的视觉样式（比如沿用框架默认 disabled 样式），又需要提交值时，可移除 disabled，改用 CSS 和属性控制交互：
- 移除
disabled属性，避免被表单忽略 - 添加
style="pointer-events: none;"阻止鼠标事件（点击、选择等） - 设置
tabindex="-1"移出 Tab 键焦点流，防止键盘激活 - 注意：部分屏幕阅读器可能仍将其识别为可操作元素，无障碍支持弱于原生
disabled
服务端必须校验，前端禁用不可信
无论用 disabled、readonly 还是 CSS 隐藏交互，用户都能通过 DevTools 轻松修改 DOM 并提交任意值。所有关键字段的合法性、权限和业务规则，必须在服务端二次验证。
例如：一个本应只读的 <input name="user_id">，即使前端完全锁死，后端也得检查该字段是否与当前登录用户匹配，而不是直接入库。
真正容易被忽略的不是怎么“看起来禁用”，而是忘了服务端这道防线——它才是唯一可靠的控制点。
