乐于分享
好东西不私藏

PortLite 源码开源后,最值得改的不是界面,而是这 3 个能力

PortLite 源码开源后,最值得改的不是界面,而是这 3 个能力

PortLite 源码发出来以后,数据比我预期好一些。

上一篇主要是把项目地址、运行方式和核心结构补上。说白了,就是先把这个 Windows 端口查看器开源出来,方便想折腾 Wails + Go 桌面工具的朋友自己跑一遍。

但源码发完以后,我反而没那么想马上继续写“怎么把界面做得更好看”。

端口查看器这个东西,最容易做成一个 netstat 表格版。能用,甚至也挺直观,但如果只是把命令行结果搬到桌面窗口里,它的上限其实不高。

真要继续改,我更关心的是另一件事:

它能不能更贴近本地开发时的排障流程。

因为本地服务起不来时,真正让人烦的不是“我不知道 Windows 有什么命令能查端口”,而是每次都要在端口、PID、进程名、项目目录、启动脚本之间来回确认。

PortLite 现在已经能查端口、看 PID、看进程名和路径,也能在确认后结束进程。

接下来如果还要继续做,我觉得最值得改的不是界面,而是下面这 3 个能力。

先把无关端口藏起来

我之前做第一版的时候,有个很明显的感受:端口信息一旦完整展示出来,反而会有点吵。

本机上同时跑着浏览器、IDE、数据库、Docker、各种后台服务时,端口列表不会很短。你想找的是 300051738080 这些开发端口,但界面里可能同时混着一堆系统进程、浏览器连接、临时端口。

信息是有了,但你还是得自己筛。

所以 PortLite 后面第一个值得改的点,不是把表格颜色调得更漂亮,而是默认帮人少看一点无关信息。

比如我会优先考虑这些过滤:

  • 只看 LISTENING 状态
  • 只看本地地址 127.0.0.1 和 0.0.0.0
  • 只看常见开发端口,比如 300051738080884833066379
  • 保存一组自己常用的项目端口
  • 启动后优先提示“可能影响本地开发的端口”

这里的重点不是“加一个搜索框”。

搜索框当然有用,但它解决的是“我已经知道要找什么”。开发时更常见的情况是:服务起不来,只看到一句 address already in use,人还没完全进入排查状态。

这时候如果工具默认把真正关心的端口摆出来,会比给你一个完整列表更舒服。

我自己现在更想要的是这种视图:

常用开发端口 3000   已占用   node.exe 5173   空闲 8080   已占用   java.exe 8848   空闲 3306   已占用   mysqld.exe 6379   已占用   redis-server.exe 

这样一眼就能知道,本地开发环境大概哪里堵住了。

完整端口列表当然还要保留,但它应该更像一个“展开看详情”的入口,而不是一打开工具就把所有东西都倒出来。

查到进程以后,先给安全操作

看到 PID 以后,很多人第一反应可能是:那就加个一键结束进程。

PortLite 现在确实已经有结束进程的能力,而且做了确认弹窗和一些基础保护。比如 PID 0、PID 4、PortLite 自己的进程不会让你直接结束。

但如果继续往下做,我反而不想把“一键结束”做得太顺手。

原因也很简单:端口占用只是麻烦,误杀进程才是真的麻烦。

一个 PID 背后可能是本地数据库,可能是 Docker,可能是 IDE 拉起来的子进程,也可能是某个你暂时没想起来的服务。你看见它占了 8080,不代表它就一定该被关掉。

所以在“结束进程”之前,我更想先补一组安全操作。

比如:

  • 复制端口排查命令
  • 复制结束进程命令
  • 打开进程所在目录
  • 查看进程路径
  • 显示进程启动时间
  • 标记常见开发进程和系统进程

这里有个取舍我觉得挺重要。

工具可以把命令准备好,但不要让用户闭眼点。

比如查到 8080 被某个 PID 占用后,PortLite 可以直接给出:

netstat -ano | findstr :8080tasklist | findstr 12345taskkill /PID 12345 /F 

但最后要不要执行,最好还是让人自己确认。

这个设计看起来慢了一步,其实更适合排障工具。

排障工具第一件事不是帮你动系统,而是把信息整理到足够清楚,让你知道下一步该不该动。

我现在越来越不喜欢那种上来就“智能清理”“一键修复”的按钮。

尤其是开发者工具。

开发环境里很多东西不是垃圾,它只是刚好在占端口。直接杀掉当然爽,但爽完以后,可能另一个服务就开始报错了。

再往前一步,做启动前检查

现在的 PortLite 还是一个偏被动的工具。

服务启动失败了,端口被占用了,我再打开它查一下。

这已经比手敲命令舒服一点,但还不够。

我后面更想试的是:让它往前走一步。

不是等服务报错以后再查,而是在启动前就先检查一组端口。

比如我平时一个本地项目可能会用到这些东西:

前端:5173 后端:8080 管理后台:3000 MySQL:3306 Redis:6379 Nacos:8848 

每次切项目时,这组端口是不是空闲,其实比完整端口列表更有价值。

如果 PortLite 可以保存一个“项目端口组”,点一下就检查:

项目 A 5173   空闲 8080   被 java.exe 占用 3306   被 mysqld.exe 占用 6379   被 redis-server.exe 占用 

那它就不只是端口查看器了。

它会更像一个本地开发前的检查面板。

这个方向我觉得比单纯优化主题色、换布局更有意思。因为它不是让工具更像一个工具,而是让它进入真实工作流。

本地服务启动失败时,查端口是被动排障。

启动前检查端口,是主动避坑。

两者只差一步,但使用感觉完全不一样。

后面甚至可以继续扩展一点,但不用急着做大:

  • 保存多个项目端口组
  • 给端口加备注,比如“前端 dev server”“后端 API”“本地 Redis”
  • 有冲突时显示占用进程和路径
  • 一键复制排查信息
  • 后台托盘提醒,但先不默认常驻

这些功能听起来都不复杂,真正要小心的是边界。

PortLite 还是应该保持轻。它可以帮我检查开发环境,不应该变成另一个笨重的系统管理软件。

为什么不是先改界面

界面当然可以继续打磨。

比如表格密度、状态颜色、空状态、搜索体验、深色主题,这些都能做,而且做完以后截图也会好看一些。

但现在这个阶段,我更想先确认工具到底要解决什么问题。

如果场景没想清楚,界面改得再精致,也只是一个更好看的端口列表。

PortLite 第一版解决的是:

本地服务起不来时,我想知道端口被谁占了。 

如果继续往下做,我希望它解决的是:

本地开发前,我想知道常用端口是不是已经被占了。 

这个变化比换一套 UI 更重要。

因为前者是“出问题以后查一下”,后者是“启动之前先看一眼”。

一个工具什么时候真的变得顺手,往往不是功能最多的时候,而是它刚好卡在你原本会烦的那个动作前面。

这篇先把想法记下来

PortLite 现在还是一个很小的项目,代码也不复杂。

但我越来越觉得,这类本地工具有意思的地方,不是把某个命令包一层界面,而是把平时排查问题时那些零散动作串起来。

查端口、看 PID、看进程名、判断能不能关、复制命令、启动项目前检查端口。

这些动作单独看都很小,但每天本地开发时反复遇到,就会变成一种不太明显的摩擦。

后面如果继续改,我大概率会先从“常用端口组”和“更安全的进程信息”开始,而不是急着把一键结束进程做得更显眼。

毕竟端口占用只是麻烦。

误杀进程才是真的麻烦。