密码安全依赖属性组合、https传输与后端校验，而非仅type="password"；autocomplete需设为current-password或new-password并配对用户名字段，且区分大小写、禁用预设value。
单纯写 type="password" 不代表密码安全，它只做字符遮掩；真正起作用的是属性组合、传输协议和后端配合。
autocomplete 属性怎么设才有效
现代浏览器（Chrome 120+、Safari 16.4+）基本忽略 autocomplete="off"，强行使用反而干扰密码管理器识别。关键不是“关掉”，而是“说清楚”语义：
-
autocomplete="current-password"：用于登录页，必须搭配type="password"和一个同表单内的autocomplete="username"或autocomplete="email"字段 -
autocomplete="new-password"：用于注册或改密页，提示浏览器不要填充旧密码；但若表单里没有对应字段（如“确认新密码”），Chrome 可能直接跳过该提示 - 值区分大小写，
Current-Password或NEW-PASSWORD无效 - 不能预设
value（包括 JS 初始化赋值），否则浏览器可能判定为“已有内容”而触发填充
pattern + minlength 是体验优化，不是安全防线
pattern 和 minlength 能在提交前给出即时反馈，但它们完全可被绕过：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 用户禁用 JS 后，所有前端校验失效
- 用 DevTools 直接删掉
required或修改minlength="1"，表单照常提交 - 正则表达式如
pattern="(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,}"只影响 UI 提示，不阻止明文提交 - 后端必须重复校验——且不能只校验长度，要检查是否含常见弱口令（如
12345678、password）
HTTPS 是硬性前提，其他都是补丁
没有 HTTPS，所有前端防护都形同虚设：
- 抓包工具（Wireshark / Chrome Network 面板）能直接看到 POST 请求体里的明文密码
- 哪怕你用 Web Crypto API 在前端做了 AES 加密，密钥也暴露在 JS 中，攻击者可逆向或 patch 加密逻辑
- 证书必须有效：不能是自签名、不能过期、不能域名不匹配
- 页面内所有资源（JS/CSS/iframe）也必须走 HTTPS，否则混合内容会降级或阻断
name 和 form 结构影响密码管理器行为
密码管理器是否自动填充，不取决于你写了多少属性，而取决于它能否识别出“这是一个标准登录流程”：
-
name值要规范：name="password"比name="pwd"更易被识别；name="new_password"比name="np"更可靠 - 密码
<input>必须嵌套在<form></form>标签内，且<form></form>最好有action和method="POST" - 单独一个密码框（无用户名字段、无表单包裹）大概率被管理器忽略
- React/Vue 动态渲染时，
autocomplete属性容易在 hydration 后丢失，需在挂载后立即确认存在
最容易被忽略的点：密码框的安全性，不取决于你加了多少属性或 JS，而取决于你有没有让浏览器按设计工作——包括允许密码管理器填充、支持无障碍访问、不破坏语义结构。强行“防填充”，往往把用户推向粘贴明文、写在便签上等更不安全的习惯。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
