autocomplete 属性是浏览器识别字段语义的信号灯，非开关；必须严格按 whatwg 规范书写大小写敏感的标准 token，初始 html 中声明，且 type 与 autocomplete 协同，否则静默失效。

autocomplete 属性根本不是“开关”，而是浏览器识别字段语义的信号灯——写错、写漏、写晚，它就直接不亮。

autocomplete="off" 为什么在密码框里基本没用

Chrome ≥76、Edge、Safari 主动忽略 autocomplete="off"，尤其当字段是 type="password" 且表单中存在 type="email" 或 type="tel" 时。这不是 bug，是浏览器强制保障密码管理器可用性的策略。

• 写 autocomplete="off" 给密码框，Chrome 可能反而弹出“生成新密码”建议
• autocomplete="false"、autocomplete="nope" 等非标准值，会被当作无效，部分浏览器仍按 on 处理
• 真正有效的做法是：登录页用 autocomplete="current-password"，注册/改密页用 autocomplete="new-password"
• 确认密码字段也必须设 autocomplete="new-password"，否则 Safari 可能复用上一个生成的密码填进两个框

语义值写错等于没写，浏览器不报错也不提醒

WHATWG 规范定义了严格大小写敏感的 token 列表，拼写偏差、大小写错误、自定义命名（如 user_email、full_name）都会被静默忽略，降级为模糊字符串匹配，体验极差。

Pptx To Html

使用 MinerU 将 PowerPoint (.pptx) 演示文稿转换为 HTML，保留幻灯片内容与结构，生成可直接在网页使用的 HTML格式。

下载

• autocomplete="Email"（首字母大写）→ 被忽略
• autocomplete="user-email" → 当作未设置，等同于没写
• autocomplete="name" 不推荐；应拆成 autocomplete="given-name" + autocomplete="family-name"，否则 Safari 拒绝建议
• 地址字段必须用 shipping street-address 而非 shipping_address，前缀 shipping 和空格都是规范要求

动态插入 input 时 autocomplete 很容易失效

Chrome 和 Safari 要求 input 在页面初始 DOM 中已存在、且未被 JS 预设过 value（哪怕设为空字符串），否则会认为“用户已操作过”，跳过自动填充逻辑。

• React/Vue 中在 useEffect 或 mounted 里动态创建 input 并赋值 ref.current.value = "" → autocomplete 失效
• SSR 渲染后 hydration 阶段若清空 value 同时删掉了 autocomplete 属性 → Chrome 重新扫描 DOM，意外激活填充
• 单独存在的 input（不在 form 标签内）即使写了 autocomplete="cc-number"，也大概率被跳过
• 必须在 HTML 字符串中直接写入 autocomplete 属性，JS 动态 setAttribute 补充几乎无效（Safari 尤其严格）

type 和 autocomplete 必须协同，否则语义失效

type 决定输入行为（键盘类型、校验、UI），autocomplete 决定填充依据，二者不匹配时，浏览器要么忽略填充，要么触发错误匹配。

• type="tel" + autocomplete="tel" → 弹出数字键盘 + 填充历史手机号
• type="text" + autocomplete="tel" → 键盘仍是全键盘，填充逻辑不触发
• type="date" + autocomplete="bday" → Chrome 才识别为生日并唤起日期选择器
• type="number" + autocomplete="tel" → 类型冲突，填充逻辑失效
• type="search" 不支持任何 autocomplete 值，浏览器直接忽略

最易被忽略的一点：autocomplete 的生效前提是字段在初始 HTML 中存在、属性值完全符合规范、且未被 JS 过早干预 value 或移除属性——它不是运行时可协商的配置，而是一次性声明式契约。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！