autocapitalize仅控制软键盘首字母行为，不校验或修改输入值；需按字段类型选off/none、words、sentences或characters，并与autocorrect协同设置，且不适用于中文拼音输入法。
autocapitalize 不是“自动处理”，它只是告诉软键盘怎么弹出首字母——写对了不报错，写错了也不警告，但用户输错就是你的表单问题。
autocapitalize 值选错就白写了
它不是 CSS 或 JS，不改 value，只影响键盘行为。选错值不会报错，但用户在 iOS 键盘上会反复输小写，比如姓名字段设成 sentences，结果 “zhang san” 一直保持小写；而该用 off 的密码框没设，用户习惯性输 Password123，实际提交却是 password123 导致登录失败。
-
off或none：密码、用户名、邮箱本地部分（user@domain.com中的user）必须用 -
words：适合英文姓名、标题、品牌名；中文拼音输入法可能响应（如输入zhang san→Zhang San），但不保证，别依赖它做校验 -
sentences：纯英文评论/反馈类<textarea></textarea>；iOS 稳定，Android 多数 WebView 只识别英文标点（.?!），对中文句号「。」基本无反应 -
characters：序列号、验证码、SKU（如SKU-ABC123）；它只影响键盘实时输入，粘贴进来的sku-abc123仍是小写
写了 autocapitalize 却没反应？90% 是被覆盖了
它极易被更高优先级机制压制，真机测试前先排除这些：
- JS 直接改 value：
input.addEventListener('input', e => e.target.value = e.target.value.toLowerCase())—— 键盘刚弹出大写，又被脚本转回小写，光标还乱跳 - 封装组件没透传：Vant 的
<van-field></van-field>必须显式写:input-props="{ autocapitalize: 'off' }"，否则属性丢在组件外层 - 写在
<form></form>上想“全局控制”：iOS Safari 不支持继承，必须每个<input>单独写 -
type或inputmode冲突：type="number"、type="email"、inputmode="numeric"下该属性完全被忽略——数字键盘压根没有大小写切换能力 -
autocorrect="off"：部分旧版 WebKit 会连带禁用autocapitalize
type 和 autocorrect 必须协同设置才稳定
iOS 要求同时满足两个条件：type 不能是 password 或 search（这两个类型强制禁用首字母大写），且 autocorrect 不能为 off（否则系统认为你不需要任何输入辅助）。
- ✅ 正确示例：
<input type="text" autocapitalize="words" autocorrect="on"> - ❌ 无效组合：
<input type="password" autocapitalize="sentences">、<input type="text" autocapitalize="sentences" autocorrect="off">、<input type="search" autocapitalize="words"> - 别指望它对中文拼音输入法生效——只有英文键盘模式下才响应
真正要“自动处理”，得靠 JS 或后端
autocapitalize 纯属客户端提示，用户仍可手动切小写、粘贴全小写、甚至绕过键盘直接赋值 input.value = 'hello world'。业务若要求强格式（如注册姓名必须首字母大写），必须补足：
- 前端监听
input事件：e.target.value = e.target.value.replace(/(^|\s)\w/g, c => c.toUpperCase())，注意避开中文、emoji 和变音符号（如é） - 服务端统一格式化：比前端更可靠，避免客户端差异和绕过
- 别用
text-transform: uppercase：只是视觉伪装，input.value仍是小写，提交、校验、API 接收全出问题
最容易被忽略的一点：它对中文拼音输入法无效，且 Android 各厂商键盘支持程度极不一致——三星、华为、小米键盘对 words 的响应率可能低于 40%。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
