开发者被Docker文档逼疯18次后，干脆自己造了个免联网神器

凌晨两点，你正在写Dockerfile。光标停在HEALTHCHECK后面，手指悬在键盘上——interval和period到底哪个是参数名？timeout默认值是30秒还是5秒？start-period这个flag真的存在吗，还是你记混了？

你熟练地切到浏览器，输入"dockerfile healthcheck options"。Stack Overflow第一条答案来自2017年，高赞但已过时；第二条对了，但引用的参数名早被改掉。再翻三条，打开官方文档，找到正确章节，关掉五个标签页——三分钟没了，刚才的flow state碎了一地。

这个场景，Docker用户平均每周经历3.7次（我编的，但你懂）。一位被折磨多年的开发者终于忍无可忍，花两周造了个零后端、零登录、能离线跑的交互式速查工具。

三栏设计：把"查文档"压缩到一次hover

整个应用就一块屏幕，左边是指令速查表，中间是实时高亮的Dockerfile，右边是深度参考。18条Dockerfile指令按用途分类，带实时搜索和标签过滤。鼠标悬停任意指令卡片，tooltip秒出摘要；点击后右面板同步刷新。

中间面板是重头戏：一段真实的、多阶段Node.js生产环境Dockerfile，token级别的语法高亮。FROM、RUN、COPY、HEALTHCHECK这些关键词全是可交互的span。

鼠标悬停HEALTHCHECK，参数说明直接弹在代码旁边——没有新标签页，没有上下文切换。

点击任意关键词，右面板展开完整文档：语法格式、所有可用参数、默认值、版本变更历史、官方最佳实践。原本需要跳转四五个页面才能凑齐的信息，现在一次点击搞定。

技术栈刻意做减法：Next.js + 一个JSON文件

作者用Next.js配Tailwind CSS搭的前端，没有后端服务，没有数据库，没有外部API。全部知识库塞进一个DATA.json，构建时直接导入。

语法高亮也没用大而全的Prism或Shiki，自己写了个轻量tokenizer，按Dockerfile的语法规则切分token。代码量小到可以贴在文章里，维护成本趋近于零。

这种设计有个副作用：整个站点可以离线运行。PWA缓存一次，飞机上也照样查。对于经常断网或担心文档站挂掉的开发者，这比任何花里胡哨的功能都实在。

为什么官方文档做不到？

Docker官方文档其实全、也准，但结构是为"系统学习"设计的。你想快速确认某个参数的写法，得先选对文档版本，再导航到正确章节，再在一堆解释性文字里定位到语法行。

这个速查工具反着来：假设你已经知道要干什么，只是忘了具体怎么写。交互路径从"阅读文档"变成"指向代码、获得答案"，认知负荷降了一个数量级。

作者把项目开源在GitHub，叫Docker Hub——对，和官方镜像站撞名了，搜的时候得加"cheatsheet"关键词。部署在Vercel，免费额度够用。

上线两周，Hacker News讨论区最高赞评论是："终于有人做了我一直想做的事。"另一条更扎心："Docker Inc. 应该把这个买下来，然后放进官方CLI。"

但Docker Inc. 没动静。他们的文档团队过去一年在忙别的事：把参考手册从Markdown迁到新的CMS，给搜索框加了AI问答——结果用户反馈是"更慢了，而且AI会胡说"。

这个单文件JSON的速查工具，某种程度上是对复杂化趋势的反叛。作者没写一行后端代码，没调一次大模型，解决的问题却比很多"智能化"改造更具体。

项目README里有个细节：作者列了"不会做的功能"，包括用户账户、云端同步、团队协作。理由是"每加一个功能，加载时间就长一点，而我现在打开页面是0.8秒"。

这种克制在产品经理视角里挺罕见。多数工具做到后期都会膨胀，但这个项目的目标用户太明确了——就是那些"知道自己在干嘛、只是偶尔忘语法"的人。功能边界守得越死，核心体验越锋利。

目前DATA.json已经覆盖全部18条Dockerfile指令，但作者留了接口：社区可以PR补充更复杂的示例，比如多平台构建的FROM语法，或者BuildKit特有的RUN --mount变体。

有个用户提了issue，问能不能支持docker-compose.yml。作者回复："暂时不想做，那会破坏现在的单文件简洁性。但如果你fork出去做Compose版本，我可以链接过去。"

这种回应方式本身也是产品态度的延伸：不追求大而全，但愿意让生态自己长出来。

你现在写Dockerfile时，平均要跳几次浏览器查文档？如果有个离线可用的零延迟速查工具，你会把它钉在浏览器标签页，还是继续用 muscle memory 硬背参数？