很多网站不是“不能上线”，而是暂时不适合完全公开。
比如你刚把一个作品集、客户演示页、活动预热页或者新版本首页发出来，链接已经能打开了，但你心里其实很清楚：
- 现在还在走内部 review
- 还没到正式官宣时间
- 只想先给少量客户看
- 页面内容能展示，但不希望被所有人直接访问
这种时候，最轻的一条路通常不是重新开一套测试环境，也不是去自己折腾服务器层的 Basic Auth，而是给网站加一层访问密码。
如果你手里已经有一个可访问的网址，接下来最值得做的，就是先决定它应该“完全公开”还是“受控开放”。
图：对预览站、作品集和客户演示页来说，访问密码的价值不是“更高级”，而是让上线和公开变成两个不同动作。
哪些场景最适合先加访问密码
访问密码最适合这些情况：
1. 客户预览
项目已经可以给客户看了，但还没到正式交付节点。你希望客户能打开链接、看完整页面、在手机上点一点，但不希望这个地址被继续转发扩散。
2. 作品集筛选
有些作品适合公开展示，有些只适合在面试或商务沟通时按需发送。尤其是带客户品牌、内部提案、未发布设计稿的项目，先加密码会比“先公开再撤回”稳得多。
3. 活动页预热
域名、页面、HTTPS 都已经准备好了，但上线时间还没到。你想先做走查、确认移动端体验、让业务方验收，这时候访问密码就是一层很实用的缓冲。
4. 团队内部联调
产品、设计、前端、运营都要看同一个链接，但你又不想让搜索引擎、外部访客、误点链接的人提前看到。
如果你还没把网站真正发成公网链接，可以先看这篇入门文章：HTML 文件怎么变成网址？。
静态网站做密码保护，难点不在“有没有一个密码框”
很多人以为，密码保护的关键只是做一个输入框。
真正的问题是后面这些细节：
- 访问成功后，用户要不要每次都重新输入？
- 同一个访客在手机和电脑上要不要分别验证？
- 输错很多次时，怎么防止暴力尝试？
- 自定义域名下是否还能正常工作？
- 页面资源、HTML、跳转逻辑是不是都走同一套保护规则？
也就是说，密码保护不是“把一个表单放到页面前面”就结束了，它本质上是一套访问控制流程。
如果你自己搭服务器，这一层通常要么落在 Nginx，要么落在网关、Worker、Serverless、鉴权中间层。对于只是想发一个作品集或预览站的人来说，这套成本往往太重了。
更实用的思路：把“发布”与“公开”拆开
对静态网站来说，一个更合理的做法是：
- 先把网站正常发布出来
- 再决定这个项目当前是公开访问，还是密码访问
- 需要时随时打开或关闭这层保护
这样做的好处很直接：
- 你不用维护两套环境
- 你可以继续用正式域名做验收
- 你能把链接发出去，但访问权仍然可控
- 页面准备好以后，去掉密码就能直接转入公开状态
这比“先不上线，等万无一失再说”更接近真实交付。
配置前，先想清楚 3 件事
1. 这是一层长期门禁，还是短期预览
如果只是让客户这周先看一下，你要的是一种短期可控的入口。
如果这个作品集会长期半公开，比如只给面试官或商务联系人看，那你要的是更稳定的访问方式，包括：
- 固定密码
- 更清晰的分享规则
- 定期更新密码的习惯
2. 要不要让访客“记住我”
这件事非常实际。
如果每次刷新都重新输密码，体验会很差；但如果长期记住，控制力又会下降。所以在很多场景里，更好的选择不是极端，而是分情境：
- 内部验收、短期 review：允许记住我
- 严格控制、敏感展示：缩短记住时间或不启用
3. 你是要保护“页面本身”，还是保护“敏感信息”
访问密码适合保护可预览页面，不适合替代真正的数据权限系统。
如果页面里已经写进了敏感接口、测试密钥、内部数据、未脱敏内容，那么问题不在密码层，而在你不该把这些信息放进前端静态资源里。
在上码里，密码保护更适合哪些项目
如果你用的是上码这类静态托管路径，访问密码比较适合这些项目：
- 客户演示页
- 作品集网站
- 预热中的 landing page
- 需要先验收再公开的活动页
- 内部先走查的博客或文档站
从产品能力上说，这类方案的价值在于：它不要求你额外准备服务器登录、代理层或独立鉴权服务，而是把密码保护放进项目设置里统一管理。
对上码来说，这项能力更适合已经进入正式交付阶段的项目，因此它更偏向 Pro / Team 阶段的项目控制能力，而不是“新手先上再说”的默认流程。
用户访问时，实际发生了什么
如果你只是想知道结论，可以理解成下面这条链路：
- 用户访问你的项目地址
- 系统先判断这个项目是否开启了访问密码
- 如果没开启，直接放行
- 如果已开启，先返回密码页
- 验证通过后，系统用 Cookie 记住这次访问状态
- 后续请求在有效期内直接放行
这套流程比“纯前端弹一个输入框”更可靠，因为保护逻辑发生在分发层，而不是只靠浏览器本地脚本自觉判断。
以当前上码的实现为例，它会把访问状态保存在签名 Cookie 中，并支持“记住我”这一类更贴近真实使用习惯的行为。默认情况下，不勾选“记住我”是较短时效；勾选后可以延长到多天，适合持续 review 的场景。对异常尝试，还会配合限流，避免一个公开链接被人无限试密码。
对于用户来说，体验上最明显的区别是：
- 该输密码的时候才输一次
- 通过后不会每次刷新都被打断
- 正式域名和预览地址都可以沿用同一条访问路径
最稳的一套配置动作
无论你用哪个平台，这套检查顺序都值得照着做一遍：
1. 先在项目设置里开启密码保护
不要先发链接，再去想“之后补一个密码层”。顺序反过来，通常会更容易出错。
2. 再决定是否允许“记住我”
如果是短期评审，允许更顺手；如果是高频转发或人员复杂的场景，建议更保守。
3. 用无痕窗口走完整个访问流程
重点测试这些点：
- 首次访问能否正确跳到密码页
- 输入正确密码后能否进入站点
- 刷新后是否仍保持状态
- 自定义域名下是否表现一致
- 退出后是否真的恢复到受保护状态
4. 再把链接发给别人
很多“密码保护失效”的问题，其实不是功能坏了，而是自己在已登录状态下测试，误以为外部用户也会直接看到页面。
如果你后面还要接正式域名，可以和这篇文章一起看：静态网站怎么绑定自定义域名？。
哪些情况不适合只靠访问密码
这件事很重要。
访问密码适合保护“谁能看见页面”，不适合保护“谁能访问敏感系统”。
下面这些情况，不建议只靠密码页：
- 页面里包含真实隐私数据
- 前端资源里暴露了测试密钥或内部接口
- 链接背后接的是未做权限控制的后端服务
- 你需要记录不同成员的细粒度访问身份
换句话说，访问密码更像一道项目级门禁，不是完整的账号权限系统。
一个更像交付团队的判断标准
什么时候该给网站加密码？
很简单，看一句话：
这个链接现在是否“能看”，但还不适合“到处传播”？
如果答案是“对”，那就应该先加。
它的价值不在于制造神秘感，而在于让你的交付流程更可控：
- 可以先上线，再慢慢公开
- 可以先让客户 review，再官宣
- 可以让作品集在需要时分享，而不是长期裸奔
对大多数静态网站来说，这层控制恰好够用。
常见问题
访问密码会影响自定义域名吗？
正常的项目级密码保护应该和访问地址一起工作，无论你访问的是平台临时域名还是已经绑定好的正式域名，逻辑都应该一致。真正需要确认的是，你有没有在正式域名下也走一遍完整测试。
搜索引擎还能抓到被密码保护的内容吗？
通常不能完整抓到。因为对爬虫来说，它首先拿到的不是正文，而是受保护入口。所以如果你希望某篇内容被收录，就不要把它长期放在密码后面。
只想给客户临时看一段时间，最稳的做法是什么？
先开密码，把项目发给客户验收；确认没问题后，再决定是继续保留密码，还是切到正式公开状态。这比“先公开，出问题再撤”更稳，也更像真实交付流程。
最后的建议
很多人把“上线”理解成“所有人都能看”。
其实在真实项目里，这往往不是一回事。
更成熟的做法是把流程拆开：
- 上线，是让链接可访问
- 公开，是决定谁现在可以访问
如果你的网站已经能打开，但还没准备好完全放开，那访问密码就是下一步最轻、也最实用的动作。
等你确认页面稳定、链接正确、域名和 HTTPS 都没问题，再把它真正公开出去，会稳很多。
