纯静态HTML无法可靠实现密码和有效期校验，必须依赖服务端（如Vercel Edge Functions、Cloudflare Workers）完成密码哈希比对与JWT exp校验；若仅用HTML，只能通过时间戳命名、JS提示、prompt输入等弱防护应对临时场景。
HTML本身不支持密码和有效期校验
纯静态 HTML 没有服务端逻辑，password 输入框、input[type="password"] 或 localStorage 存个时间戳，都拦不住用户右键“查看源码”或直接绕过前端 JS。所谓“HTML 实现权限”，实际是把校验逻辑伪装成前端操作，但真正生效必须依赖后端或托管平台能力。
常见错误现象：404 页面硬塞一段 JS 判断时间，结果用户禁用 JS 就直接进去了；或者用 document.cookie 写个过期时间，但 cookie 可手动修改、无法防篡改。
- 所有密码验证必须由服务端完成（哪怕只是 Cloudflare Workers、Vercel Edge Function 这类轻量后端）
- 有效期必须由服务端签发 token（如 JWT）并校验
exp字段，不能只靠前端Date.now() - 静态托管（GitHub Pages / Netlify / Vercel 静态部署）无法单独实现该功能，必须搭配函数或代理层
用 Vercel Edge Functions 做轻量校验
如果你用 Vercel 托管 HTML 项目，可以加一个 /share/[id]/route.ts 边缘函数，接管所有分享链接请求。它能读 URL 参数、校验密码、检查有效期，再决定是否返回真实 HTML 或重定向到登录页。
使用场景：小团队内部文档、活动页临时分享、设计稿预览链接，不想搭完整后端。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 路径规则示例：
/share/abc123→ 触发函数，从环境变量或 KV 中查abc123对应的password_hash和expires_at - 密码不存明文，用
crypto.subtle.digest()在函数里比对哈希（如 SHA-256），避免泄露原始密码 - 有效期用 ISO 时间字符串存（如
"2025-04-10T18:00:00Z"），函数内用new Date().toISOString()对比，避免时区误差 - 校验失败时返回
403或重定向到/share/login?from=/share/abc123，不要在 HTML 里暴露校验逻辑
Netlify Functions + _redirects 绕不过去的坑
Netlify 也能做类似事情，但要注意它的 _redirects 文件和函数执行顺序：重定向规则优先于函数，如果写成 /share/* /api/share/:splat 200，就等于把所有请求都甩给函数，但函数返回 HTML 时，浏览器地址栏仍是 /share/xxx —— 这没问题；但如果函数返回 302 跳转，又没配好 headers，可能触发缓存导致失效。
容易踩的坑：
-
_redirects里不能写动态条件（比如“仅当时间未过期才放行”），它只是静态路由表 - 函数里用
context.clientContext拿不到真实 IP，做限流或设备识别不可靠 - 密码参数别走 URL（如
?pwd=123），会被日志、CDN 缓存、Referer 泄露；必须走POSTbody 或Authorizationheader - Netlify 的 KV（
@netlify/blobs）目前不支持 TTL，得自己在值里存过期时间并每次校验
真静态场景下最务实的妥协方案
如果确定只能用纯 HTML（比如客户只给一个 FTP 目录），那就放弃“可靠权限”，转向“友好提示+成本门槛”组合：
- 分享链接命名带时间戳，比如
report_20250410_v2.html，过期后你删文件，用户访问直接404 - 首页加醒目
<div id="expiry-warning"></div>，JS 读取页面内硬编码的data-expire="2025-04-10"并对比当前日期，过期就display: none全部内容，只留提示 - 密码用
prompt("请输入访问密码：")，正确才document.body.innerHTML = ...渲染真实内容 —— 不防技术用户，但能挡住大部分误点进来的人 - 所有敏感数据（如 API key、内部接口地址）绝对不要出现在 HTML 源码里，哪怕注释掉也不行
复杂点在于：时间判断依赖用户本地时钟，密码哈希得提前算好塞进 JS，而一旦 JS 被保存下来，整个“保护”就形同虚设。所以这类方案只适合生命周期短、受众可控、且不怕被传播出去的临时内容。
