autocapitalize是HTML原生属性，用于控制移动端软键盘首字母大写规则，支持none/sentences/words/characters值；iOS Safari支持最全，Android WebView表现碎片化，常见失效原因包括JS覆盖、UI库未透传或type不匹配。
autocapitalize 是原生 HTML 属性，作用是直接干预移动端软键盘的首字母大写行为，不是视觉样式，也不依赖 JS —— 它告诉键盘“接下来该按什么规则大写”，iOS Safari 支持最稳，Android WebView 表现参差不齐。
autocapitalize 值怎么选？看输入场景
值不是随便填的，必须匹配字段语义，否则用户输起来别扭甚至出错：
-
none（推荐替代off）：密码、邮箱、URL、用户名等大小写敏感字段必须用它，避免 iOS 键盘强行大写首字母导致输错 -
sentences：评论、反馈、描述类<textarea>最常用；iOS 识别.?!后空格，但 Android 多数不认中文句号「。」 -
words：姓名（如“Zhang San”）、标题、品牌名；注意 Android 部分 WebView 会把所有单词首字母都大写，包括 “and”、“the” -
characters：极少见，比如要求全大写的激活码输入框；实际中容易引发误触，慎用
写了 autocapitalize 却没生效？先查这三处
失效几乎从不因为拼写错误，而是被更高优先级逻辑覆盖或绕过：
- JS 直接操作了
.value，比如input.addEventListener('input', e => e.target.value = e.target.value.toLowerCase())，这会立刻抹掉键盘的大写状态 - 用了封装组件（如 Vant 的
van-field或 Ant Design Mobile 的InputItem），它们默认不透传autocapitalize，得显式通过inputProps或attrs传进去 - 用了
contenteditable="true"的 div 模拟输入框 —— iOS 完全不支持该属性在非原生<input>/<textarea>上生效
和 type 属性冲突吗？优先级关系要理清
autocapitalize 和 type 是协同关系，不是互斥。但某些 type 会自带隐式行为，覆盖你的设置：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
type="email"、type="url"、type="password"默认忽略autocapitalize，无论你设成啥，键盘都强制小写 —— 所以这类字段设none其实是冗余的，但保留更明确 -
type="text"是唯一能自由发挥的类型；如果本该是邮箱却用了type="text"，又没设autocapitalize="none"，iOS 键盘大概率首字母大写，用户一输就错 - 表单级设置（如
<form autocapitalize="none">）会被子元素显式声明覆盖，但可作为兜底方案
和系统输入法开关的关系
它不是开关的“补充”，而是“指令”：
- 页面设了
autocapitalize="none"，哪怕用户在 iOS 设置里开了「首字母大写」，键盘也不会触发 - 页面完全不设该属性，才由系统输入法开关决定行为 —— 这会导致安卓/iOS/不同输入法体验不一致，所以必须显式声明
- 注意：某些越狱机或第三方中文输入法（如搜狗国际版英文模式）压根不响应这个属性，属于已知兼容性黑洞，无法靠前端修复
真正难搞的不是写对值，而是确认它有没有被 UI 库吞掉、有没有被 JS 覆盖、有没有被 type 类型静默屏蔽 —— 这三点漏查任意一个，属性就等于没写。
