Kiri：用 Rust 写的本地开发端口管理 CLI，能看清端口背后的进程
拨开当地发展港口的迷雾。平台支撑平台|状态 | - | - | macOS arm64/x64 |支持 | Linux x64 |支持 | Windows x64 |支持 | Linuxarm64 / Windowsarm64 |计划|在 MacOS 上，Kiri 使用 lsof、ps、tail、MacOS 日志命令和可选的 Docker 元数据。
秒懂
- 它是什么？
- Kiri 是一个用 Rust 写的本地开发端口管理 CLI，专注于快速查看端口对应的进程、内存、框架和健康状态，并支持追踪日志和清理进程。它解决了开发者在多个服务间切换时端口混乱的痛点，但平台支持仍有局限。
- 适合谁用？
- Kiri 适合那些经常在多个本地服务间切换、需要快速定位端口对应进程并查看日志的开发者，尤其是使用 MacOS 或 Linux x64 的用户。它不适合需要跨平台 ARM 支持或依赖 Docker 映射的用户，因为 Linux arm64 和 Windows arm64 仍在计划中，Docker 只是可选项。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 32 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
端口迷雾：Kiri 要解决的具体问题
本地开发时，端口号常常变成一串没有意义的数字。你启动了一个前端、一个后端、一个数据库，然后忘了 3000 是谁，5432 是谁。更麻烦的是，有些进程根本不监听端口，比如 AI 编程工具启动的 MCP Server。Kiri 就是为这个场景设计的：它用 `ports` 命令列出端口、进程、PID、内存占用、项目名、检测到的框架、运行时间和健康状态。它面向的是需要频繁管理多个本地服务的开发者，尤其是那些用 AI 编程工具、会留下后台进程的人。Kiri 的 README 明确说，它能显示“不监听端口的开发相关进程”，比如 Codex 或 Claude Code 启动的 MCP Server。
机制拆解：lsof、ss、PowerShell 和 /proc 的组合
Kiri 的底层机制依赖操作系统自带工具，而不是自己实现端口扫描。在 MacOS 上，它使用 `lsof`、`ps`、`tail` 和 MacOS 的 `log` 命令；在 Linux 上，它使用 `ss`、`ps` 和 `/proc`；在 Windows 上，它使用 PowerShell/CIM 的 `Get-NetTCPConnection`。这意味着 Kiri 本身是一个薄封装，把系统命令的输出整理成结构化表格。Docker 是可选的，如果 Docker 不可用或没有容器运行，Kiri 会继续工作，只是没有容器映射信息。这种设计让 Kiri 的二进制很小，但也意味着它依赖系统的命令行为，如果某个系统命令的输出格式变了，Kiri 可能需要更新。
状态标签的细节：healthy、orphaned 和 zombie 的区别
Kiri 用三个状态标签区分进程健康度。`healthy` 表示进程在运行且父进程正常；`orphaned` 表示进程还在运行，可能还在监听端口，但启动它的父进程已经退出，比如你关掉了终端或 IDE 任务，但子服务还在跑；`zombie` 表示进程已退出，但操作系统还没回收进程记录。这个区分很实用，因为开发中常见的情况是：你关掉了终端，但服务还占着端口。Kiri 能直接告诉你这个进程是孤儿进程，而不是僵尸进程，避免你误杀。
上手与命令：从 npm 到 Homebrew 的安装路径
Kiri 提供了多种安装方式。最直接的是 npm：`npm install -g @gaossr/kiri@latest`。MacOS 用户推荐用 Homebrew：`brew install gaossr/tap/kiri`。MacOS 和 Linux 可以用安装脚本：`curl -fsSL https://raw.githubusercontent.com/GaoSSR/Kiri/main/scripts/install.sh | bash`。Windows 用户用 PowerShell：`irm https://raw.githubusercontent.com/GaoSSR/Kiri/main/scripts/install.ps1 | iex`。这些方式都使用预编译的二进制，不会在本地编译 Rust。核心命令包括 `ports` 查看端口列表，`ports <port>` 查看单个端口详情，`ports kill <port>` 杀掉端口对应的进程，`ports logs <port|pid> -f` 跟踪日志。`ports ps` 可以查看不监听端口的后台进程。
日志追踪与 ANSI 色彩：好看但有限制
`ports logs <port|pid> -f` 是 Kiri 的一个亮点，它能跟踪匹配进程的日志，并用 ANSI 颜色高亮时间戳、日志级别、进程 ID、追踪 ID、源类、HTTP 值和结构化字段。README 提到它支持 Java、Python、Go、Node.js、logfmt 和 JSON 日志格式。但这里有个关键限制：对于通过终端启动的服务，Kiri 需要依赖一个稳定的文件日志，比如 `.dev-logs/service.log`，才能从另一个进程跟踪输出。如果服务没有写文件日志，Kiri 可能无法跟踪。这意味着 `ports logs` 的实际效果取决于你的服务是否配置了文件日志，而不是 Kiri 能凭空捕获所有输出。
平台支持与局限：ARM 和 Docker 的缺口
Kiri 目前支持 MacOS arm64/x64、Linux x64 和 Windows x64，但 Linux arm64 和 Windows arm64 还在计划中。这意味着如果你用树莓派或 ARM 服务器，可能无法使用预编译二进制。Docker 是可选的，如果 Docker 不可用，Kiri 会继续工作，但没有容器映射信息。在 Windows 上，进程工作目录是“best-effort from executable paths”，也就是说可能不准确。这些限制意味着 Kiri 不是全平台通用的工具，它的核心体验在 MacOS 和 Linux x64 上最好。
替代方案与对比：port-whisperer 的启发
Kiri 在 README 中明确提到它受到 port-whisperer 的启发，特别是“让本地开发端口更容易看到、理解和清理”的想法。port-whisperer 是另一个端口管理工具，但 Kiri 用 Rust 重写，并增加了 `ports ps` 来显示不监听端口的进程，以及更丰富的状态标签和日志着色。如果你只需要一个简单的端口查看工具，port-whisperer 可能足够；但如果你需要处理 AI 工具进程和日志跟踪，Kiri 的功能更贴合。Kiri 的独特之处在于它把端口管理和进程管理结合在一个 CLI 里，而不是像 lsof 那样只给出原始输出。
维护与升级成本：Apache-2.0 与活跃开发
Kiri 使用 Apache-2.0 许可证，这意味着你可以自由使用、修改和分发，但需要保留版权声明。项目最近一次提交是 2026 年 7 月，发布了 v0.1.24，版本号还很低，说明 API 可能不稳定。维护者提供了 `cargo fmt`、`cargo test`、`cargo clippy` 等开发命令，以及 `scripts/perf-smoke.sh` 和 `scripts/verify-release.sh` 这样的性能冒烟测试和发布验证脚本。升级成本方面，由于版本号低，你需要关注每次更新的 changelog，因为命令行为可能变化。但安装方式多样，升级只需要重新运行安装命令。
编辑结论
Kiri 适合那些经常在多个本地服务间切换、需要快速定位端口对应进程并查看日志的开发者，尤其是使用 MacOS 或 Linux x64 的用户。它不适合需要跨平台 ARM 支持或依赖 Docker 映射的用户，因为 Linux arm64 和 Windows arm64 仍在计划中，Docker 只是可选项。采用前应先验证你的平台是否在支持列表内，并检查 `ports logs` 对目标框架日志的 ANSI 解析效果，因为并非所有日志格式都能被正确着色。Kiri 的杀手级功能是 `ports ps` 能显示不监听端口的 AI 工具进程，这对 Codex 或 Claude Code 用户有实际价值，但如果你主要用 Windows，建议先确认 PowerShell/CIM 的进程工作目录获取是否满足需求。
社区笔记