autocapitalize仅对可编辑文本控件生效，如text、email、textarea及contenteditable元素，不适用于number、checkbox、password、readonly/disabled输入框；主要支持ios safari和chrome for ios，android多数浏览器忽略该属性。
autocapitalize 在哪些输入场景下生效
这个属性只对可编辑的文本控件起作用，比如 <input type="text">、<input type="email">、<textarea></textarea>，还有设置了 contenteditable="true" 的元素。它对 <input type="number">、<input type="checkbox"> 或只读（readonly）/禁用（disabled）状态的输入框完全无效。
- iOS Safari 和 Chrome for iOS 是主要支持平台；Android 大部分浏览器忽略该属性（包括新版 Chrome Android）
- 即使写了
autocapitalize="sentences"，如果用户手动关闭了系统键盘的自动大写，它也不会触发 - 在
<input type="password">上设置它，iOS 会直接无视——密码框默认禁用首字母大写
四个合法值的实际行为差异
autocapitalize 接收四个字符串值，但它们在不同输入类型下的表现并不一致：
-
"none"：强制关闭键盘首字母大写，适用于用户名、代码输入等场景 -
"sentences"：句首大写（遇到句号、问号、感叹号后下一个词首字母大写），但 iOS 键盘实际只识别英文标点，中文句号（。）不触发 -
"words"：每个单词首字母大写，对中文无意义，对英文名（如 “john doe” → “John Doe”）有用 -
"characters"：全部转大写，适合缩写输入（如 “usa” → “USA”），但用户无法输入小写字母，需谨慎使用
注意：autocapitalize="on" 或 "off" 是非标准值，部分旧文档里出现过，现代浏览器不识别，应避免使用。
和 autocomplete、inputmode 搭配时的优先级问题
autocapitalize 不会覆盖 inputmode 的语义，但两者可能冲突：
-
<input inputmode="numeric" autocapitalize="none">：键盘弹出数字键盘，autocapitalize无效果（数字键盘本就不做大写） -
<input autocomplete="email" autocapitalize="none">：iOS 仍可能默认开启首字母大写，因为autocomplete="email"会触发邮箱专用键盘，其行为优先级高于autocapitalize - 如果同时设了
autocapitalize="words"和inputmode="lowercase"，后者无效——inputmode不控制大小写，只影响键盘类型
真实建议：优先用 autocapitalize 控制大小写行为，inputmode 仅用于提示键盘类型，不要指望它们协同“精准控制”。
为什么加了 autocapitalize 却没反应
最常见原因不是写错了值，而是被其他因素屏蔽了：
- 父元素或自身有 CSS
text-transform: uppercase，这会掩盖原生首字母行为（且无法取消已转大的字母） - 使用了第三方输入组件（如 React 的受控
input），JS 层拦截了输入事件并重写了 value，导致原生键盘策略失效 - 在 WebView（尤其是 Android 的系统 WebView）中，该属性基本不工作，别依赖它做关键逻辑
- 某些 CMS 或富文本编辑器（如 TinyMCE）会移除或忽略该属性，需检查最终渲染出的 HTML 是否还存在
验证方法：用 Safari 真机打开页面，聚焦输入框，看键盘左下角的 shift 键是否按预期切换状态——这是最直接的判断依据。
移动端键盘行为离“标准”很远，autocapitalize 是个弱提示，不是强约束。真正需要确定格式的字段（比如邮箱、用户名），得靠 JS 在提交前校验和修正。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
