autocapitalize 是软键盘提示指令，仅对原生 input/textarea 有效，需与 type、autocorrect 协同并真机验证；选值依内容类型：off/none（大小写敏感字段）、sentences（英文评论）、words（姓名标题）、characters（全大写）。
autocapitalize 不是“开了就生效”的开关，而是软键盘收到的提示指令；它只在原生 <input> 和 <textarea></textarea> 上起作用，且极易被 JS 操作、封装组件或系统输入法覆盖。
autocapitalize 值怎么选？看输入内容类型
选错值不会报错，但用户实际输入体验会脱节：
-
off或none：密码、邮箱、用户名等大小写敏感字段必须用。iOS 默认对type="text"启用首字母大写，不设这个，用户一输就错 -
sentences：仅在纯英文反馈、评论类场景较可靠；中文句号「。」基本不触发，iOS 支持好，Android WebView 多数忽略标点逻辑 -
words：适合姓名、标题等单词分隔明确的字段；中文拼音首字母是否大写取决于键盘实现，不是强制行为 -
characters：全大写模式，等效于 Caps Lock；注意它不改变用户粘贴内容的大小写，只影响键盘实时输入
为什么写了 autocapitalize 却没反应？
失效几乎从不因为拼写错误，而是被更高优先级机制压制：
- JS 代码里写了
input.addEventListener('input', e => e.target.value = e.target.value.toLowerCase())，直接抹掉键盘的大写意图 - 用了 Vant、Ant Design Mobile 等 UI 库的
Input组件，它们默认不透传autocapitalize，得显式通过inputProps或attrs传入 - 把
autocapitalize写在<form></form>上想“全局生效”，但子元素未继承（只有部分浏览器支持继承，iOS Safari 不支持） - 用了
contenteditable="true"区域——该属性在 iOS 上完全无效，必须换回原生<input>
和 type 属性、autocorrect 怎么配合？
单独设 autocapitalize 是低效的，它常和另外两个属性协同工作：
立即学习“前端免费学习笔记（深入）”；
-
type="email"或type="url"本身会触发对应键盘，并隐式启用autocapitalize="none"；此时再显式写autocapitalize="off"属于冗余，但无害 -
type="password"默认禁用首字母大写，但 iOS 旧版本（iOS 12 之前）仍有例外，保险起见仍建议加autocapitalize="off"和autocorrect="off" -
autocorrect="off"必须和autocapitalize="off"配套使用；否则即使首字母不自动大写，拼写纠正仍可能把 “user” 改成 “User”
Android 和 iOS 行为差异最常踩的坑
别假设“写了就能用”，不同平台响应程度天差地别：
- iOS Safari 对
sentences和words支持最完整，但仅限英文键盘；中文键盘基本无视所有值 - Android WebView（尤其旧版 Chrome）多数只识别
off/none和sentences，characters常被忽略 - 第三方输入法（如搜狗、百度、讯飞）在 H5 页面中可能完全不读取该属性，尤其是越狱/定制 ROM 设备
- 测试时务必真机验证：模拟器里的软键盘行为 ≠ 真实用户所见
真正关键的不是“支持哪些值”，而是你能否控制住输入法最终呈现的键盘行为——这需要 type、autocapitalize、autocorrect 三者组合 + 真机验证，缺一不可。任何环节松动，用户就在那里反复删改首字母。
