autocapitalize是移动端软键盘原生提示指令，非开关也非强制转换；它仅影响键盘首字母状态，不改变实际输入值，无法替代JS或后端格式化。
autocapitalize 不是开关，而是键盘提示指令；它不改变实际输入值，也不能替代 JS 或服务端格式化。
autocapitalize 值怎么选才不翻车
选错值不会报错，但用户在 iOS 键盘上会反复输错小写——关键看字段语义，不是“想大写就写 words”：
-
none：密码、验证码、API Key 等必须全小写/大小写敏感的场景（推荐替代off，语义更明确） -
sentences：英文反馈、评论、描述类<textarea>（iOS 支持最稳，识别.?!后空格触发） -
words：英文姓名、标题（如<input type="text" autocapitalize="words">），但 Android 多数输入法（Gboard、三星键盘）忽略它 -
characters：缩写词、许可证码、纯英文代码标识符（视觉上全大写，但注意：它不转换 value，只是键盘显示）
为什么写了 autocapitalize 却没反应
失效几乎从不因为拼写错误，而是被其他机制静默覆盖：
- 用了
type="email"、type="tel"、type="password"或type="search"—— 这些类型会强制忽略autocapitalize - 同时设了
autocorrect="off"：旧版 WebKit 会连带禁用autocapitalize - 第三方 UI 组件（如 Ant Design Mobile 的
Input）未透传该属性，需通过inputProps显式传入 - JS 监听了
input事件并执行了el.value = el.value.toLowerCase()，直接覆盖键盘行为 - 在
contenteditable区域里使用 —— iOS Safari 完全不支持
和 type / inputmode / autocorrect 怎么共存
这几个属性会互相压制，顺序和组合决定最终行为：
立即学习“前端免费学习笔记（深入）”；
-
type="text"+autocapitalize="words"+autocorrect="on"：iOS 上最可能生效的黄金组合 -
inputmode="numeric"或inputmode="decimal"：直接让autocapitalize失效，系统判定“这是数字，不需要字母大小写” -
type="url"：协议部分（https://）强制小写，autocapitalize="words"对域名无效；得换用type="text" inputmode="text" -
spellcheck="false"可搭配autocapitalize="words"使用，避免拼写下划线干扰首字母逻辑（尤其姓名字段）
真要确保首字母大写，还得靠 JS 或后端
autocapitalize 是“尽力而为”的提示，不是数据保障。用户仍可：
- 长按键盘 Shift 手动切小写
- 粘贴全小写文本（比如从微信复制 “john doe”）
- 用外接蓝牙键盘绕过软键盘逻辑
所以关键字段（如注册姓名）必须补一手：input.addEventListener('input', e => { e.target.value = e.target.value.replace(/(^|\s)\w/g, c => c.toUpperCase()); });
注意：这个正则对中文、emoji、连字符（如 “mary-jane”）不友好，生产环境建议用更健壮的分词逻辑或交由后端统一 ucfirst。
