浏览器禁止直接修改input.type从password到text，因type是规范定义的不可变属性，旧版Safari/iOS WebView会清空值或抛异常；可靠方案是双input切换显隐或用inputmode+CSS模拟明文效果。
为什么不能直接改 input.type 从 password 切到 text
浏览器对 input[type="password"] 有安全限制，部分旧版 Safari 和某些 iOS WebView 在运行时修改 type 属性会清空输入值，甚至抛出 DOM 异常。这不是 bug，而是规范行为——type 是不可变属性（per spec），强行赋值可能被忽略或触发重置。
真正可靠的做法是**不改 type，而是用两个 input 元素切换显隐**，或用现代方案绕过 type 切换。
- Chrome/Firefox 支持运行时改
type，但行为不一致：Firefox 保留值，Chrome 可能清空 - iOS Safari 15.4+ 已修复，但低版本仍存在输入框失焦、光标丢失问题
- 若必须单 input 切换，需在改
type前缓存value，改完再恢复，并手动 focus + setSelectionRange
推荐方案：用 inputmode + autocomplete 配合图标切换视觉状态
不碰 type，只控制 inputmode 和样式，让密码字段在视觉上“像文本”——比如加一层半透明蒙版、覆盖图标、动态调整字体和间距。核心是让用户感知变化，而非真实改变 type。
示例逻辑：
立即学习“前端免费学习笔记（深入）”；
<div class="password-field">
<input type="password" id="pwd" autocomplete="current-password">
<button type="button" aria-label="显示密码" onclick="togglePassword(this)">
<span class="icon-eye"></span>
</button>
</div>
- 点击按钮时，只切换
input的class（如加showing），并更新aria-label和图标 - CSS 中用
.password-field.showing input { font-family: monospace; letter-spacing: 0.05em; }模拟明文观感 - 不改
type，规避所有兼容性风险；表单提交仍走标准password流程
如果坚持单 input 切换 type：必须做三件事
仅当项目明确要求“真切换 type”且已放弃低版本 iOS 支持时才考虑。否则跳过这节。
- 保存当前
value和光标位置：const val = el.value; const pos = el.selectionStart; - 先设
el.type = 'text'，再立即el.value = val，再el.setSelectionRange(pos, pos) - 监听
blur事件，在失焦前强制切回password，否则用户离开页面时密码明文暴露在 DOM 中
注意：setSelectionRange 在 iOS 上需在用户手势回调中调用（如 onclick），否则无效。
更现代的替代思路：用 <input type="text"> + inputmode="text" + 密码掩码逻辑
完全放弃 type="password"，用普通 text input，靠 JS 实时遮盖字符（如显示 ●●●●，但 value 始终是明文）。好处是完全可控，支持复制、粘贴、自动填充；坏处是需自行处理密码强度提示、防粘贴明文等逻辑。
- 监听
input事件，用正则过滤非密码字符（如禁止中文、控制长度） - 渲染层用
<span contenteditable="false">●●●●</span>覆盖在 input 上，同步宽度和位置 - 提交前取原始
value，不是遮盖后的文本
这种方案适合需要深度定制体验的管理后台，但对普通登录页属于过度设计。
真正容易被忽略的是：密码显示/隐藏功能从来不只是“换个 type”，它牵扯到焦点管理、无障碍支持（aria-live 提示）、移动端软键盘类型（inputmode="numeric" 会错乱）、以及 autofill 兼容性——哪怕你只是加了个小眼睛图标，也得测一遍 Chrome Autofill、Safari Password AutoFill、1Password 插件是否还能识别字段。
