调试Docker容器时，大多数人都在重复同一套动作：先docker ps -a找容器，眯眼选中名字，复制粘贴到docker logs，再复制粘贴到docker inspect，最后docker exec进去。容器名字明明没变，shell却帮不上忙，手动复制还容易把哈希前缀搞错。
开发者Nick Ciolpan做了个小工具叫dux，用Rust写成的单二进制文件，同时提供终端界面（基于ratatui）和浏览器界面（基于axum）。它内置105条精选的Docker命令，每次执行后会解析输出内容，自动预填下一条命令的参数。
安装很简单：brew install nickciolpan/tap/dux，然后dux启动终端界面，dux serve打开本地网页版（http://127.0.0.1:7878/dux）。代码开源在GitHub，MIT协议。
这个工具的核心设计只有两个关键概念。
第一，每条命令都是一个静态结构体，包含ID、名称、描述、详细说明、命令模板、分类、输出类型，以及后续可跟进的命令ID列表。模板用{name}作为占位符，每个占位符对应一种参数类型：容器、镜像、网络、卷、服务，或者自由文本（文件路径、环境变量、端口号等）。整个类型系统就这五种实体加自由文本，没有更复杂的层级。
第二，produces字段标明命令的输出包含什么实体。docker ps输出容器列表，docker images输出镜像列表，大多数命令则没有可解析的输出。就这两个注解，其余功能都由此推导。
每次命令执行后，解析器根据produces类型处理标准输出，返回一个结构化结果：容器名列表、镜像名列表、网络名列表、卷名列表、服务名列表。以docker ps为例，解析器很小但容错——跳过表头，每行按空白分割，取最后一列作为容器名。不依赖固定列宽，即使输出格式略有变化也能工作。
接下来是跟进命令的匹配逻辑。假设你刚跑了docker ps，输出被解析为容器列表。工具会遍历所有命令，找出那些参数类型为Container的命令，把刚才拿到的容器名预填进去。界面里这些名字可以直接选，不用手动输入。如果某条命令需要多个参数，比如同时指定容器和镜像，工具会分别用已解析的对应类型列表来填充。
浏览器界面用axum提供HTTP服务，前端是简单的HTML表单。终端界面用ratatui实现，支持键盘导航。两套界面共享同一个命令目录和解析逻辑，只是渲染层不同。
这个设计最省力的部分在于：不需要维护复杂的命令依赖图。只要声明每条命令"产出什么"和"需要什么"，匹配关系自动建立。新增命令时，填好模板和这两个注解，立刻融入整个工作流。
105条命令覆盖日常调试场景，从基础的日志查看、进入容器，到网络排查、卷管理、Compose服务操作。不是要把Docker CLI完整重做，而是把高频的调试链条串起来，减少上下文切换。
对于每天和容器打交道的开发者，这解决了一个真实的小痛点：名字在屏幕里，却要靠鼠标复制。现在它留在解析器的内存里，随时待命。
热门跟贴