最可靠的做法是监听input事件并用touppercase()修改value属性，同时保存并恢复光标位置；autocapitalize和text-transform仅影响视觉或键盘提示，不能替代js处理；关键字段必须服务端强制转大写兜底。
input事件监听 + toUpperCase() 是最可靠的做法
想让输入内容真正变成大写（不只是看起来大），必须用 JavaScript 操作 value 属性，且必须监听 input 事件——它覆盖粘贴、拖拽、IME 输入、长按选中替换等所有路径。用 blur 或 change 会漏掉实时编辑场景，用户还没失焦就已提交小写内容。
常见错误是直接写 input.value = input.value.toUpperCase() 却不保存光标位置，导致每次输入后光标跳到末尾，破坏连续编辑体验。
- 务必在修改
value后调用setSelectionRange(start, end)恢复原光标/选区位置 - 对含中文、emoji、变音符号（如 é → É）的字符串，
toUpperCase()在多数现代环境表现稳定，但某些 locale 下可能异常；若业务强依赖一致性，建议服务端再做一次转换 - 只对特定字段生效：加
data-uppercase属性或class="uppercase-input"，避免全局污染
const input = document.querySelector('input[data-uppercase]');
input.addEventListener('input', (e) => {
const start = e.target.selectionStart;
const end = e.target.selectionEnd;
e.target.value = e.target.value.toUpperCase();
e.target.setSelectionRange(start, end);
});
autocapitalize="characters" 只影响键盘，不改实际值
这个属性在 iOS Safari 和部分 Android WebView 中能让虚拟键盘默认大写，但它只是提示，不是强制。用户仍可手动切小写、粘贴小写文本、甚至用开发者工具直接改 value。
它不改变 DOM 值，也不触发任何 JS 事件，纯属 UX 辅助。如果你看到输入框“自动大写”，那其实是键盘行为，不是数据转换。
- 仅对
<input>和<textarea></textarea>生效，且type不能是password或search（这些类型 iOS 会强制禁用） - Android 支持极不稳定，Gboard、三星键盘大多忽略
characters，只响应sentences或words - 对中文拼音输入法完全无效——拼音键盘不识别该属性
text-transform: uppercase 是视觉伪装，别当真
它只改变渲染样式，input.value、表单提交、JS 读取、复制粘贴出来的仍是原始大小写。在验证码、车牌号、用户名比对等需要精确匹配的场景下，这会导致直接失败。
很多人误以为加了这个 CSS 就“搞定大小写”，结果后端收不到大写，或者用户复制表单内容发给别人时还是小写。
- 对中文、数字、标点符号无任何效果，只作用于 ASCII 字母和部分拉丁扩展字符
- 若同时用了 JS 转换和该 CSS，可能造成视觉重复（比如 “Hello” → 显示为 “HELLO”，但 JS 又转一次，逻辑冗余）
- 适合纯展示场景：按钮文字、标题、静态表格表头
关键字段必须服务端兜底
前端任何手段都可被绕过：禁用 JS、手动改 DOM、curl 提交、爬虫直连 API。如果业务要求“必须大写”，服务端收到后第一件事就得做 value.toUpperCase() 或等价处理。
尤其注意混合场景：比如用户先输 “abc”，再粘贴 “123def”，再手动删掉 “123”，最后剩 “abcdef”——这种操作链里，仅靠监听 input 仍可能漏掉中间状态，服务端校验才是最后一道防线。
容易被忽略的是：大小写敏感的校验逻辑（如邮箱本地部分）和服务端存储格式必须统一，否则同一用户用不同大小写注册两次，数据库可能存两条记录。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
