autocapitalize 支持 off、none、sentences、words、characters 五个值，其中 none 推荐替代 off；iOS Safari 支持最全，Android WebView 支持较碎片化，常见失效原因包括 JS 覆盖、UI 库未透传属性或 type 不匹配。

autocapitalize

是 HTML 表单控件（主要是 和 ）的原生属性，用于控制移动端软键盘在输入时是否自动将首字母大写。它不依赖 JavaScript，也不受系统输入法设置影响，是 Web 页面层面对输入行为的直接干预。

autocapitalize 支持哪些值？

该属性有四个标准取值，不同浏览器支持程度略有差异（iOS Safari 最完整，Android WebView 表现较碎片化）：

• "off"：完全禁用自动大写（包括句首、单词首、所有字母）
• "none"：同 "off"，语义更明确，推荐替代 "off"
• "sentences"：每句话开头自动大写（识别句号、问号、感叹号后空格）
• "words"：每个单词首字母大写（适用于姓名、标题等）
• "characters"：全部字母强制大写（类似 Caps Lock 效果）

注意："sentences" 在 iOS 上效果稳定；Android 多数 WebView 仅支持 "sentences" 和 "words"，且对标点识别较弱（比如不识别中文句号「。」）。

为什么加了 autocapitalize 却没生效？

常见失效原因不是代码写错，而是被其他机制覆盖或忽略：

• 输入框绑定了 input 或 change 事件并手动调用 .value = .value.toLowerCase() 等操作，直接覆盖了软键盘的大写逻辑
• 使用了第三方 UI 库（如 Ant Design Mobile、Vant）的封装组件，其内部可能未透传 autocapitalize 属性，需显式通过 inputProps 或 attrs 传入
• 设置了 type="text" 但实际期望是邮箱/URL 场景——此时应优先用 type="email" 或 type="url"，它们自带合理的默认 autocapitalize 行为（如 email 默认为 "none"）
• iOS Safari 在 contenteditable 区域中不支持该属性，必须用原生 /

和系统输入法的「句首大写」开关冲突吗？

不冲突，但有优先级关系：

• autocapitalize 是页面级指令，软键盘会优先遵循它
• 系统输入法的「句首字母自动大写」开关（如华为/搜狗/QQ 输入法里的设置）只对原生 App 或未指定该属性的网页起作用
• 若页面设了 autocapitalize="off"，即使用户在系统里打开了句首大写，软键盘也不会触发
• 反过来，如果页面没设该属性，系统设置才生效——这意味着跨设备体验不一致，所以建议显式声明

典型场景示例： —— 这比依赖用户自己开闭输入法开关更可控。

textarea 和 input 的表现差异

两者都支持 autocapitalize，但实际体验有细微差别：

• 在 iOS 上对 "sentences" 支持更好，换行后新行开头也能触发大写（只要前一行以句末标点结尾）
• 是单行，一般只在光标位于行首或句末标点+空格后触发，对连续输入更敏感
• Android 部分机型（尤其旧版 Samsung Keyboard）对 的 autocapitalize 支持较差，有时退化为始终小写，此时可考虑 fallback 到 inputmode="text" + JS 监听并修正（但代价是失去原生体验）

不要为了“统一”而强行用 JS 模拟大写逻辑——软键盘的预测、纠错、滑动输入等功能会因此降级，真实用户打字效率反而下降。

移动端表单中，autocapitalize 是最轻量、最直接的首字母控制手段，但它不是万能开关。关键在于理解它和系统输入法、浏览器实现、封装组件之间的边界——漏掉任一环，就容易出现「写了却没用」的困惑。

大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！