纯HTML无法实现真正密码保护，必须依赖服务器（如Nginx HTTP Basic Auth）或托管平台（如Cloudflare Pages密码功能）；前端JS校验（prompt、遮罩层）可被轻易绕过，仅适用于防路人。
HTML本身不支持密码保护，别被“纯HTML实现”误导
HTML是静态标记语言，没有服务端逻辑，password输入框或prompt()弹窗这类前端校验，用户按F12就能绕过、直接看到源码里的密码或跳转链接。所谓“HTML带密码访问”，实际必须依赖服务器行为（如Nginx鉴权、PHP路由判断）或第三方托管平台能力（如Vercel/Netlify的密码保护预发布环境），纯HTML文件双击打开或扔进GitHub Pages都做不到真正防护。
Nginx配置HTTP Basic Auth是最轻量可靠的方案
如果你能控制服务器（比如自己搭的VPS、NAS或支持自定义Nginx的托管服务），用auth_basic配auth_basic_user_file是最简单且被广泛支持的方式。它在请求到达你的HTML前就拦截，连index.html都不会下发给未授权用户。
常见错误现象：403 Forbidden而不是弹登录框 → 检查auth_basic_user_file路径是否绝对路径、文件权限是否为644、用户文件是否用htpasswd生成（不能手写）；404返回空白页 → 确认Nginx配置已重载（nginx -s reload）且location块覆盖了你的HTML路径。
- 用
htpasswd -c /etc/nginx/.htpasswd username生成用户文件（首次加-c） - 在server或location块里加：
auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/.htpasswd;
- 确保Nginx有读取
.htpasswd的权限（非root运行时尤其注意）
GitHub Pages + Cloudflare Pages这类静态托管怎么加密码
它们不让你改服务器配置，所以得换思路：用Cloudflare Pages的Password protection功能（仅Pro及以上计划），或把公开链接换成带签名的临时URL（需配合后端）。GitHub Pages原生不支持任何密码层，所有声称“GitHub Pages密码保护”的教程，本质都是前端JS校验——无效。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
使用场景：快速分享一个原型给客户看，又不想公开源码。Cloudflare Pages可直接在项目设置里开启Password protection，填一个密码就行，它会在CDN边缘节点拦截请求，比自己搭Nginx更省事。
- Cloudflare Pages密码保护对
/和子路径统一生效，但无法区分用户权限 - 如果用
fetch()加载本地data.json，密码页仍可能暴露该文件路径——静态资源仍可被直接请求，除非也设为私有 - 不要把密码硬编码在HTML里（比如
if (pwd === "123")），这等于没锁门
真要“纯前端”就只能接受它不安全，只做体验层遮罩
如果完全无法接触服务端（比如只允许上传到某企业内网共享目录），那唯一能做的，是用CSS+JS做个登录遮罩层，让用户输对密码才display: none掉遮罩并显示内容。但这只是障眼法，懂点浏览器操作的人5秒就能拿到全部HTML、CSS、JS和资源链接。
性能影响几乎为零，但兼容性要注意：localStorage存密码状态时，Safari无痕模式默认禁用；用prompt()在Chrome 92+已废弃，会触发控制台警告。
- 遮罩层必须用
position: fixed; z-index: 9999盖住整个body - 密码验证后，建议用
history.replaceState()清除URL里的?pwd=xxx痕迹 - 别用
eval()或Function()动态执行密码逻辑——这会让代码扫描工具直接报高危
复杂点在于：你得想清楚，这个“密码”到底防谁？防随手点开的路人，JS遮罩够用；防有意查看源码的合作方，就必须上服务端或托管平台的真鉴权。没分清这点，选什么方案都会踩坑。
