autocapitalize 是移动端软键盘原生提示指令，非CSS/JS控制；值需按输入场景选：off（密码等）、words（姓名）、sentences（英文评论）、characters（序列号）；失效多因被JS、组件封装或type限制覆盖。
autocapitalize 不是 CSS 或 JS 控制逻辑，它是直接告诉移动端软键盘“怎么弹出首字母”的原生提示指令；写对了不一定立刻生效，写错了也不会报错——失效几乎全是被其他机制覆盖导致的。
autocapitalize 值怎么选才匹配真实输入场景
选错值不会报错，但用户在 iOS 或 Android 键盘上会反复输错。关键不是“语法对不对”，而是“这个字段用户到底输什么”：
-
off：密码、用户名、邮箱本地部分（如user@domain.com的user）必须用。iOS 默认对type="text"启用首字母大写，不设这个，Password123就成了常见登录失败原因 -
words：姓名、标题、品牌名等单词边界清晰的英文字段；中文拼音输入法可能响应（如“zhang san”→“Zhang San”），但不保证，别依赖它做数据校验 -
sentences：纯英文评论、反馈类<textarea>；iOS 支持稳定，Android 多数 WebView 仅识别英文标点（.?!），对中文句号「。」基本无反应 -
characters：序列号、验证码、缩写码（如SKU-ABC123）；它只影响键盘实时输入，粘贴进来的sku-abc123仍是小写
为什么写了 autocapitalize 却没反应
90% 的“没生效”问题和拼写无关，而是被更高优先级行为压制：
- JS 里写了
input.addEventListener('input', e => e.target.value = e.target.value.toLowerCase())—— 直接把键盘刚输的大写又转回小写，光标还跳动 - 用了 Vant / Ant Design Mobile 等封装组件，但没透传属性：
<van-field input-align="right" :input-props="{ autocapitalize: 'off' }" />才有效 - 把
autocapitalize写在<form>上想“全局控制”，但 iOS Safari 不支持继承，必须每个<input>单独写 -
type="number"或inputmode="numeric"下该属性完全被忽略——数字键盘压根没有大小写切换能力
autocapitalize 和 type / autocorrect 必须协同设置
单独设 autocapitalize 是低效的，它常和 type、autocorrect 组合使用才能真正控住输入体验：
立即学习“前端免费学习笔记（深入）”；
-
type="email"默认隐式启用autocapitalize="none"，再显式写autocapitalize="off"没问题，但没必要；而type="password"在旧版 iOS（iOS 12 前）仍有例外，保险起见仍要加autocapitalize="off" autocorrect="off" -
autocorrect="off"必须和autocapitalize="off"配套：否则即使首字母不自动大写，拼写纠正仍可能把 “user” 改成 “User” -
type="search"或type="url"可用autocapitalize="off"关闭首字母，但type="tel"或type="date"下该属性无效，别白费劲
和 text-transform: capitalize 的本质区别
这是最容易混淆的一点：text-transform: capitalize 是纯视觉层操作，不影响实际值；autocapitalize 是输入层干预，直接影响 DOM 中的 .value：
- 设
autocapitalize="words"→ 用户输 “john doe”，键盘自动弹出 J 和 D 大写，input.value就是"John Doe" - 只设
style="text-transform: capitalize"→ 用户输 “john doe”，input.value仍是"john doe"，只是显示像"John Doe" - 需要服务端接收真实大写数据时，必须用
autocapitalize，而不是靠 CSS 或 JS 补位
最常被忽略的复杂点是：autocapitalize 的效果高度依赖键盘实现，iOS Safari 最稳定，Android 各厂商 WebView 差异大，且完全不处理粘贴内容——如果你的业务要求“所有输入都大写”，得在提交前用 JS 做兜底，而不是只信这个属性。
