密码输入框必须使用<input type="password">而非type="text"伪装，因其具备浏览器底层保护；需配合HTTPS、精确autocomplete值、autocapitalize等属性，并依赖服务端校验与安全策略。
密码输入框必须用 <input type="password">，别用 type="text" 加样式伪装
浏览器对 type="password" 有底层保护：不缓存明文、禁用自动填充（除非显式允许）、阻止开发者工具直接读取 value（在某些上下文中），而用 type="text" + CSS 遮盖只是视觉欺骗，value 依然可被脚本轻易获取、被调试器看到、被录屏或键盘记录器捕获。
- 永远不要写
<input type="text" style="caret-color: transparent; text-security: disc;">这类“伪密码框” - 确保表单提交走 HTTPS，否则
type="password"在 HTTP 下毫无意义——明文密码会裸奔到服务器 - 如果需要“显示/隐藏”切换，只改
type属性值（"password"↔"text"），不要 clone 或重渲染整个 input
禁用 autocomplete 和 autocapitalize 防止意外泄露
默认情况下，现代浏览器可能对 type="password" 自动填充已保存的凭据，也可能因系统键盘设置触发首字母大写，导致用户输错或暴露长度模式。显式关闭能减少干扰和风险。
- 加
autocomplete="off"不够可靠，应使用更精确的值：autocomplete="new-password"（用于注册页）或autocomplete="current-password"（用于登录页） - 必须加上
autocapitalize="off" autocorrect="off" spellcheck="false"，避免 iOS 键盘自动大写或拼写纠正暴露输入节奏 - 不要依赖
name="pwd"这类通用名——浏览器靠name或id匹配历史密码，用name="user_login_password"等语义弱、唯一性高的值更安全
服务端必须校验，前端掩码不是防线
type="password" 只解决“本地可见性”问题，不防 XSS、不防中间人、不防恶意扩展。真正关键的是服务端行为。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 前端 JS 不能做密码强度校验主逻辑——绕过 JS 就能提交任意字符串；校验规则（如最小长度、禁止常见密码）必须在服务端复现并执行
- 提交前若用 JS 哈希（如
sha256(password)），反而有害：服务端拿到哈希后若直接存储，等于把哈希当明文，失去加盐、慢哈希等防护能力 - 登录接口需严格限速（如 5 次/分钟/IP），并返回泛化错误信息（统一提示“用户名或密码错误”，而非区分“用户不存在”/“密码错误”）
别忽略 CSP 和 iframe 隔离带来的侧信道风险
即使密码框本身正确，页面其他部分可能引入隐患：第三方脚本窃取焦点事件、iframe 被注入恶意内容、CSS 选择器泄露输入状态。
立即学习“前端免费学习笔记（深入）”；
- 设置严格的 CSP 头：
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';—— 尤其禁用script-src 'unsafe-eval'和外部 CDN - 密码输入框所在表单不应嵌入不可信
<iframe>，否则 iframe 内脚本可通过document.activeElement或 MutationObserver 推断焦点位置 - 避免用 CSS 的
:focus-within或:has()暴露密码框是否获得焦点——某些攻击者可通过加载大量样式表探测渲染时机
input 的圆角和阴影，却忘了关掉 autocomplete 或漏配 CSP。 
