readonly在移动端表现不一致：ios safari中type="date"仍弹出选择器，android webview可能完全忽略；它仅阻止键盘输入，不阻断picker，且服务端必须校验，不可依赖前端限制。
readonly 在 iOS Safari 和 Android WebView 里表现不一致
移动端浏览器对 readonly 的交互支持比桌面端更松散。比如 iOS Safari 中，readonly 的 <input type="date"> 仍会弹出原生日期选择器，用户点选后值就被改了；而部分 Android WebView（尤其旧版 Chromium 内核）则可能完全忽略 readonly，允许长按粘贴或通过软键盘修改。
这不是 bug，是渲染层对表单控件生命周期的处理差异。关键不是“能不能设”，而是“设了之后是否真能拦住”。
- 测试时别只看 Chrome Desktop：必须在真机上用 Safari（iOS 15+）、Samsung Internet（Android 12+）、微信内置 X5 内核（v4.9+）实测
- 对
type="date"/type="time"这类原生控件，readonly仅阻止键盘输入，不阻断 picker 弹窗 —— 若业务要求绝对不可变，得换方案 - Android WebView 中若发现
readonly失效，大概率是 WebSettings 启用了setJavaScriptEnabled(true)且页面 JS 动态清除了该属性，需检查初始化逻辑
readonly + pointer-events: none 不是万能解法
有人试过给 readonly 输入框加 style="pointer-events: none;" 来禁用点击，但这在 iOS Safari 上会直接让元素无法聚焦，导致 value 无法被复制（而 readonly 原本支持复制）；在部分 Android 10 系统上还会触发 input 失焦后光标残留的 UI 残影。
更麻烦的是，pointer-events: none 对 <textarea></textarea> 无效 —— 它依然能响应双击选中、长按呼出菜单。
- 真正需要禁用所有交互（包括复制），应该用
disabled+ 隐藏域（<input type="hidden">）同步值 - 若必须保留可复制能力，优先用 CSS 视觉禁用（
opacity: 0.6; cursor: default;）配合readonly，不碰pointer-events - 永远不要依赖 CSS 层叠来“强化” HTML 行为：语义归语义，样式归样式
服务端必须校验 readonly 字段的值
所有跨端兼容方案都绕不开一个事实：readonly 是纯前端提示，用户开 DevTools 或用 curl 就能绕过。iOS 上甚至有快捷指令能批量移除页面所有 readonly 属性。
这意味着，哪怕你在 Safari 和 Chrome 里把 readonly 行为调得再一致，只要服务端没做校验，这个字段就等于裸奔。
- 校验逻辑不能只比对“是否和初始值一样”——攻击者可以先提交一次正常请求拿到 token，再伪造第二次请求篡改该字段
- 推荐方式：服务端存一份该字段的预期值（如从 session 或数据库读取），收到请求后比对，不一致直接 400 并记录日志
- 如果字段是计算得出（如订单金额 = 单价 × 数量），服务端必须重新计算，不能信任任何前端传来的“只读”结果
旧版 IE 和 Edge Legacy 对 readonly 的解析偏差
IE11 及更早版本中，readonly 在 <input type="number"> 上会失效：用户仍可通过上下箭头微调数值。这不是属性没生效，而是 IE 把 readonly 当成“禁止键盘输入”，但没拦截控件自身的操作逻辑。
Edge Legacy（EdgeHTML 内核）还有个隐藏坑：readonly 元素在表单 reset() 时会被重置为空，即使它本来有 value。
- 对 IE11 支持要求高的项目，
type="number"必须搭配 JS 监听input和change事件，手动还原 value - 避免对
readonly字段调用form.reset()—— 改用 JS 逐个赋值回初始状态 - 若已用 html5shiv，记得补上
input[readonly] { background-color: #f5f5f5; }，否则 IE 下视觉无反馈，用户以为能编辑
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
