为什么 localhost 链接分享后无法打开

只有自己的电脑能打开时，先检查发出的地址

你在笔记本上制作活动日程，预览正常，于是复制地址发给别人或生成二维码。自己的浏览器能看到日程，手机却报错。在改设计或重新生成图片之前，先看看地址里的服务器名称：本地预览不一定是已经发布到互联网的页面。

有关从手机或另一网络打开 localhost 的真实疑问有一个共同点：发送一串文字不会让处理它的服务器变得可访问。本指南区分三种情况，并提供公开日程的分享流程。它不会把开发环境变成托管服务，也不预先认定失败是账户权限问题。应先检查地址究竟指向哪里。

Localhost 指向发出请求的设备

localhost 是特殊用途名称。RFC 6761 说明它应解析到本地回环地址。通常，浏览器会在自己的设备上寻找服务。因此，笔记本的 localhost 并不能让手机识别那台笔记本。在手机打开同一地址，会尝试访问手机自身的本地环境，而你制作的日程很可能不在那里。

两个示例都是本地目标，不是公开邀请。127.0.0.1 是 IPv4 回环地址；端口 3000 用来区分服务，不会改变地址的作用范围。复制链接、添加 UTM、缩短地址或画成二维码都不会改变这个含义。把这些地址留作本地工作，不要当作任何参与者都能使用的日程目标。识别这个问题无需把地址交给外部工具测试。

http://localhost:3000/programa
http://127.0.0.1:3000/programa

私有地址也不等于发布到互联网

把 localhost 换成本地网络地址，可以属于经授权的设备测试，但不等于发布。RFC 1918 保留了私有地址段，包括 192.168.0.0/16。示例 192.168.1.25 可能标识某个特定网络中的电脑，却不是其他网络用户都能访问的通用目标。即使在同一个无线网络中，服务及访问规则也必须允许连接。

需要内部测试时，应与环境管理员约定地址和访问条件。企业网络或经授权的远程访问是另一种情况，并不是公开内部信息的理由。面向公众的日程应申请合适的已发布地址。不要为了制作海报就临时关闭防火墙或开放路由器端口。网址检查不能代替服务器的配置与保护。

http://192.168.1.25:3000/programa

为确实公开的内容获取已发布地址

发布意味着把内容放到目标受众能访问的网络服务上。MDN 区分工作文件与发布，并解释托管及网页地址的作用。如果网站由别人管理，把批准的日程交给负责人，索取最终 URL。如果自己发布，按托管服务流程操作，检查向访客提供了哪些内容和配置。

仅把 localhost 字样改成域名并不够；域名必须指向真正提供该页面的服务。虚构示例使用 example.invalid，不能作为可运行的测试网站。发布完成后再换成真实 URL。保留正确的日程路径，并检查图片、样式和链接。已发布页面若仍引用 localhost 资源，可能在自己的电脑上完整显示，在别人那里却失败。

https://example.invalid/programa

用 WikiURL 和其他环境检查公开目标

获得不含秘密的公开 URL 后，把它输入 WikiURL 的网址检查工具，查看 HTTP 响应，以及发生重定向时检测到的最终地址。工具注明不接受私有网络地址，不要用它探索自己的网络或测试本地服务。若出现限制或阻止，应在这次检查的范围内理解结果，不要自动推断所有访客都无法访问网站。

随后在手机打开已发布链接，条件允许时使用与开发电脑不同的网络。确认日程内容、图片和导航。仅有 200 响应不能证明是预期页面，也可能是首页或登录界面。技术检查和视觉审查回答不同问题。还要确认页面内的链接不会把你送回本地地址。

根据批准版本制作分享材料

完成这些步骤后，才把确认的公开地址用于消息、短链接或 WikiURL 二维码生成器。检查最终版本的目标，并在将要分发的材料中测试二维码。不要误用根据预览制作的旧文件。发布地址改变时，更新仍可控制的副本并记录批准版本，不要假设旧二维码会自动改变。

在发布记录中保存公开地址及检查结果，与开发地址分开。如果内容必须保留在内部，就保持约定的访问方式，不要只为通过外部检查而公开。目标是让地址与受众相符：本地工作面向自己的设备，内部访问面向指定人员，而日程需要从外部打开时才使用已发布网站。