远程素材包里出现 localhost，为什么换一台电脑就可能打不开？

远程包的素材地址如果指向 localhost，换电脑后就会请求接收者自己的机器。创作者电脑上的服务不会随 ZIP 一起搬过去，所以“我这里能播”不足以证明别人也能播。处理顺序是：确认实际请求地址、核对应用域名、重新导出，再用另一台设备验证。

本文由 DramaFork 整理，依据当前项目的导出与素材交付实现说明排查方法。下文的《雾港来信》、端口和现象是虚构教学例子，没有把它们当作线上实测记录。

远程链接包仍然是一个需要解压并按包内说明打开的播放器包。它把视频等资源留在服务端，通过应用域名下的素材交付入口读取。播放器页面能打开，但第一段视频加载失败，与压缩包无法解压，是两类问题。

先记录接收者拿到的包版本、发生位置、网络是否可用，以及页面显示的原始提示。若连播放器都没有打开，先按 README.txt 检查解压与启动方式；若能看见标题和选项，只是视频失败，再查素材请求。不要在尚未定位时同时修改剧本、视频和域名，否则无法判断哪个改动起作用。

检查的是实际资源地址，不是正文里有没有出现这个单词。说明文字可能提到本机测试方法，那不代表播放器真的请求了本机资源。

虚构例子中，创作者在自己的电脑上运行端口为 3000 的服务，并从这个环境导出远程包。包中的视频地址使用 localhost:3000。创作者打开时，地址指向自己的服务；接收者打开时，它指向接收者电脑上的 3000 端口。接收者没有运行同一服务，视频就无法取得。

127.0.0.1 同样表示本机回环地址。把它换成另一个本机端口，仍不能解决跨电脑分享。局域网地址只可能覆盖相应网络中的可达设备；公网出口 IP 也不能单独证明某个端口对外可达。正式交付应使用实际部署且接收者能够访问的应用域名，再验证具体素材请求。

这类检查关心地址指向谁、服务是否可达，不需要接收者在自己的电脑上复制整个创作环境。

当前导出包包含 story.json、index.html、说明与启动文件。可以用文本编辑器查看故事数据与播放器页面，搜索 localhost、127.0.0.1，确认命中是否位于视频或其他素材地址。先保留原包，不要一边搜索一边批量替换。

若熟悉浏览器开发者工具，也可查看播放时失败请求的域名和响应情况。记录域名、节点位置与错误类型即可，避免在公开反馈里贴出整条带交付凭证的素材链接。

应用首页能打开不等于每个素材入口都正常。首页与某段视频是不同请求，必须沿实际失败的位置继续检查。

当前实现会依据应用地址生成远程素材入口；配置了应用域名时，应确认它指向实际部署的服务。发现本机地址后，先由维护项目的人核对部署域名，再重新导出。旧包里已经写入的地址不会因为你修改了项目配置而自动更新。

不建议把包内所有 localhost 字符串直接替换成某个域名。资源入口还涉及路径与访问凭证，单改主机名不能证明新服务能够识别同一个项目和素材。重新导出后，应从新包的实际请求确认它使用了预期域名。

给新包一个可区分的版本名，通知接收者使用哪一份。如果两个文件都叫“最终版”，接收者可能仍然打开旧包，使已经修正的问题再次出现。

选择一台未运行创作服务的设备，解压新远程包，按说明启动，保持联网。至少检查开场、一个选择点和选择后的下一段视频；只验证开场，可能漏掉后续节点的旧资源地址。

把结果写成记录：包版本、设备与网络、走过的选择、是否加载成功、失败发生在哪。记录“待验证”与“已验证”要分开，没有另一台设备时就保留这一缺口，不能用原电脑播放代替接收者验收。

远程包依赖网络和素材服务持续可用。稳定交付入口不能解释为永久服务保证。若接收者必须完全离线，应改用本地素材包并按说明验证断网播放；这是交付条件发生变化后的选择，不能靠修改远程域名达成。

下一次交付前，先保留原包，核对一个实际失败请求，再重新导出并测试同一条路线。这样反馈能够对应到明确版本和明确资源。