在纯静态站点或演示页面中，我们常常希望限制访问者直接看到内容，或者至少不让别人轻易抄走前端逻辑。HTML本身是一种明文标记语言，所有标签、脚本、样式都会随文档下发到浏览器，因此所谓“HTML加密”并不是让文件变成密文，而是通过密码校验与脚本混淆来提高获取门槛。
一、前端密码保护的可行方案与局限
最基础的做法是在页面加载时通过JavaScript询问密码，正确后才显示主体内容。这种方法实现简单，适合屏蔽非技术用户的随意查看，但绝不能用于真正敏感的数据保护。因为前端代码对用户完全可见，攻击者只需在控制台打印出密码或在源码中找到比对逻辑即可绕过。
下面是一段典型的“前端密码遮罩”代码，它在用户输入正确前隐藏主要内容。注意这里的密码以明文写在脚本中，仅作演示：
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>简单密码保护</title>
<style>
#secret { display: none; }
</style>
</head>
<body>
<div id="gate">
<input type="password" id="pwd" placeholder="请输入密码">
<button onclick="check()">进入</button>
</div>
<div id="secret">
<h3>机密内容</h3>
<p>这里是受保护的信息。</p>
</div>
<script>
function check() {
var val = document.getElementById('pwd').value;
// 演示用密码，实际项目切勿明文写在前端
if (val === 'demo123') {
document.getElementById('gate').style.display = 'none';
document.getElementById('secret').style.display = 'block';
} else {
alert('密码错误');
}
}
</script>
</body>
</html>
这种方案的优点是无后端依赖、部署方便，缺点也极其明显：密码和判断逻辑暴露，任何人都可通过查看源代码或禁用脚本直接读取。如果必须做访问控制，应由服务端根据会话或令牌决定是否下发HTML正文，前端只负责展示。
另一种折中方式是将内容放在外部文件，前端用密码去请求，但该请求若不带服务端校验，同样能被网络面板捕获。因此前端密码保护只适合“防君子不防小人”的场景，例如内部分享页暂不让外人随意翻看。
二、使用服务端校验实现真正的访问控制
若希望密码保护有效，最佳实践是让服务器参与。用户提交密码后，后端验证并下发受保护页面或设置Cookie，后续请求凭凭证获取内容。这样HTML正文不会在未授权时抵达浏览器，从根本上避免源码泄露。
以Node.js Express为例，可以用简单的中间件实现基础鉴权。以下代码展示了一个带密码的路由保护逻辑：
const express = require('express');
const app = express();
// 简易内存会话标记，生产请用session或JWT
let authorized = false;
app.get('/secret', (req, res) => {
if (!authorized) {
const pwd = req.query.pwd;
if (pwd === 'server_side_secret') {
authorized = true;
res.send('<h1>授权成功</h1><p>这是服务端下发的保密页。</p>');
} else {
res.status(401).send('<p>需要正确密码，例：/secret?pwd=server_side_secret</p>');
}
} else {
res.send('<h1>授权成功</h1><p>这是服务端下发的保密页。</p>');
}
});
app.listen(3000, () => console.log('listen 3000'));
上述代码将密码比对放在服务端，未通过时不会返回正文。相比纯前端方案，它能有效阻止未授权者直接拿到HTML。当然生产环境应使用更安全的会话机制，比如带HttpOnly属性的Cookie或Token，避免密码出现在URL中。
需要明确的是，服务端校验解决的是“能否看到页面”的问题，而下面要讲的JS混淆解决的是“看到后能否轻易复用逻辑”的问题，两者互补而非替代。
三、JS混淆的原理与具体手段
JS混淆是在不修改程序行为的前提下，让脚本变得难以阅读和理解。常见手段包括：将有意义的函数名、变量名替换为单字母或乱码；把字符串加密，运行时再解密；打乱控制流，让顺序执行变成嵌套分支或状态机。混淆不能阻止决心逆向的人，但能大幅提高复制成本。
下面是一段未混淆与混淆后的对比示例。原始代码清晰地计算了折扣价：
// 原始代码
function calcDiscount(price, rate) {
var discount = price * rate;
return price - discount;
}
console.log(calcDiscount(100, 0.2));
经过基础混淆后，名称被替换，逻辑被包装，人类阅读难度上升：
// 混淆后示例（手工模拟）
var _0xa = function(_0xb, _0xc) {
var _0xd = _0xb * _0xc;
return _0xb - _0xd;
};
console.log(_0xa(100, 0.2));
实际工程中我们不必手写混淆，可使用工具如UglifyJS、javascript-obfuscator等。它们支持字符串数组加密、死代码注入、控制流扁平化。例如使用javascript-obfuscator时，可配置压缩变量名并加密字符串，使源码中的中文提示或接口地址不再直白呈现。
不过混淆也有代价：文件体积可能变大，调试困难，且过度混淆可能影响老旧浏览器执行效率。因此应按需选择强度，并对核心算法辅以服务端调用，不让关键规则完全落在前端。
四、HTML与JS混合防护的建议架构
如果既要给页面加密码，又要保护脚本，推荐的分层做法是：第一层由服务端控制页面可达性，未登录不返回HTML；第二层在已返回的页面中，对涉及业务规则的JS做混淆，增加复用门槛；第三层将真正敏感的计算或数据接口放在后端，前端只拿结果。
下表列出不同防护目标对应的推荐方式：
| 目标 | 纯前端是否足够 | 推荐方案 |
|---|---|---|
| 阻止外人随意浏览demo | 基本足够 | 前端密码遮罩 + JS轻量混淆 |
| 保护会员专属内容 | 不够 | 服务端会话校验，前端仅展示 |
| 防止前端逻辑被抄 | 够一半 | 强JS混淆 + 核心接口后端化 |
最后要提醒，任何声称能把HTML彻底加密、让浏览器无法查看源码的工具都是误导。浏览器必须解析并执行明文HTML与JS才能渲染页面，我们能做的只是提高获取与理解的成本，而非消除成本。合理评估风险，把真正重要的东西留在服务端，才是稳妥之道。
HTML_encryptionJS_obfuscationpassword_protection修改时间：2026-08-03 05:00:35