type="password"仅控制渲染层显示为圆点，dom中value属性始终为明文，js可直接读取；它不加密、不防抓包、不替代https和服务端哈希。
为什么 type="password" 的值在 JS 里还是明文
因为 type="password" 只控制渲染层：浏览器把输入字符画成 ●，但 DOM 中的 input.value 始终是原始字符串。这不是 bug，是设计如此。
常见错误现象：
- 在控制台执行
console.log(document.querySelector('input[type=password]').value)直接看到用户输的123456 - 用
fetch提交表单时没开 HTTPS，抓包（DevTools Network 面板）能看到password=123456明文出现在请求体里 - 服务端收到的也是明文，不会自动哈希、加盐或 AES 加密
所以它不参与任何加密流程，也不解决中间人攻击——唯一作用是防“肩窥”。
autocomplete 属性怎么配才让密码管理器正常工作
只写 type="password" 不够，现代密码管理器（1Password、Bitwarden）依赖 autocomplete 值识别语义。
关键规则：
- 登录页密码框必须设
autocomplete="current-password"，否则 Chrome 可能拒绝保存 - 注册或改密页的新密码框用
autocomplete="new-password"，比autocomplete="off"更可靠 -
name值建议用password，别用pwd或pass这类模糊名 - 表单必须包在
<form></form>里，且至少有对应用户名字段（如type="text"+autocomplete="username"）
autocomplete="off" 已被 Chrome/Firefox/Safari 大部分忽略，尤其对密码字段；autocompletetype 是过时属性，不用。
哪些属性容易漏掉却影响功能和安全
基础可用性靠几个必填属性撑着，漏一个就可能白忙活。
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
必须设置的：
-
name：没它，表单提交时该字段根本不会发到后端 -
id：没它，<label for="xxx"></label>关联失效，影响可访问性 -
required：防止空提交，前端校验不该全甩给服务端
推荐加上的：
-
minlength="8"：配合后端规则，避免弱口令直接进数据库 -
spellcheck="false"：禁用拼写检查，iOS/Android 键盘不会误标红或自动纠错 -
autocapitalize="none"：防 iOS 键盘首字母大写，破坏大小写敏感密码
绝对不要干的：
- 用
value预填密码（比如模板里插后端变量），容易被 JS 读取或日志泄露 - 把密码拼进 URL（
?password=xxx），GET 请求会被代理、CDN、服务器日志记录
前端加密能不能替代 HTTPS + 服务端哈希
不能。而且加了反而可能引入新风险。
原因很实在：
- 前端 JS 加密（比如用 CryptoJS 做 SHA256 或 AES）的密钥或逻辑暴露在源码里，攻击者可逆向、绕过或伪造请求
- 如果没开 HTTPS，加密前的数据已在网络中明文传输，加密只是“掩耳盗铃”
- 服务端收到加密后的字符串，若不验证或不二次哈希，等于把哈希值当密码存库，一旦泄露就等同于明文可登录
真正关键的安全边界只有两个：传输环节强制 HTTPS，存储环节服务端立刻用 bcrypt 或 Argon2 哈希加盐后入库。其他都是辅助。
最常被忽略的一点：很多人调通了 type="password" 就以为“密码安全已上线”，其实它连最小的安全边界都没建立——它只是个带圆点的 input。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
