本地工具突然打不开，先别急着让 AI 重写

用 Codex 做了几个本地工具以后，我遇到过一件很烦的事：刚做完时，浏览器里能打开；隔一段时间，或者电脑重启以后，同一个地址就进不去了。

最初我总以为是代码又坏了，于是把报错交给 Codex，让它重新修。后来注意到，有时它几乎没改业务逻辑，只是把服务重新启动，网页就恢复了。

问题出在我没有分清三件事：代码文件还在不在、后台服务有没有运行，以及浏览器访问的是不是那个服务的地址。

一个本地地址，需要有服务在响应

对需要本地服务的网页工具来说，打开 127.0.0.1，并不等于打开一份已经安装好的桌面 App。某个进程需要先启动，在指定端口等待请求。

例如 Node.js 官方入门示例，会先运行脚本，再用 server.listen 监听地址和端口。浏览器访问时，才有程序返回页面。示例见 Node.js 文档。

关掉启动服务的终端、进程退出，或者电脑重启以后，原来的服务可能已经停止。地址还在浏览器历史里，后台却没有东西在接它。

这时“拒绝连接”不能直接证明代码逻辑有问题。先看服务状态，通常能少走一段弯路。

另一个容易混淆的地方是 iCloud。Finder 里看得到文件名，不一定说明完整内容已经下载到这台电脑。

Apple 的说明是：开启优化储存后，在需要空间时，较旧文稿可能仅保存在 iCloud；文件或文件夹可以选择“现在下载”或“保留下载”。这不是“几天没有双击就一定删除”的固定规则。查看 Apple 说明。

代码项目会读取依赖、配置和很多小文件。目录看起来完整，却有文件无法及时读取时，排查就会变得很绕。我的原稿把这个机制说得过于绝对，整理成网站版时，改成了先检查文件实际状态。

域名、端口、路径都要保留。同一个电脑里可能有几个工具，端口记错了，也会像是程序“突然坏掉”。

同时留住报错原文。拒绝连接、文件不存在、权限不足和页面自身报错，下一步要查的东西并不一样。

看启动日志、退出信息，以及它实际监听的地址。能重新启动的，先确认是否成功启动，再打开浏览器复查。

启动失败时，保留日志继续查，不要在还没看清问题时反复安装依赖或重写整个项目。

项目是不是还在原来的目录？文件是否完整下载？运行程序有没有读取权限？依赖是否齐全？这些都比“看起来文件夹还在”更具体。

如果发现项目受云盘同步影响，我会先确认文件可以完整复制，再放到同步范围之外的工作目录。原目录先保留，等新位置运行通过以后再决定后续处理。

我更愿意把日常运行的项目放进自己主目录下的 Projects 一类专用目录，和需要云同步的办公文档分开。

目录名没有特殊功能。关键是确认它不在当前云盘同步范围里，也没有被其他同步工具接管。

给 Codex 的任务可以说得直接一点：

请检查这个本地工具为什么打不开。
先确认地址、端口、服务状态、启动日志和文件可读性。
区分已经确认的原因与还需要验证的猜测。
如果需要迁移项目，先保留原文件，在新位置运行通过后再报告。

当一个工具确实要经常使用，就值得给它做清楚的启动入口、日志位置和停止方法。适合后台运行的服务，也可以再配置相应的进程管理方式。

验收要包含一次重新启动后的检查：能不能打开、数据是否仍然存在、报错时去哪里找日志。不能只因为配置文件已经生成，就认定以后都会稳定运行。

现在再碰到本地网页打不开，我会先问：它当前有没有在运行？这个问题往往比“要不要重写”更值得先回答。