基准说不行我们还是发布了：一个 Go 日志查询工具的设计取舍

一个 76.3MB 的真实日志文件，同一查询：8 个 goroutine 并行 7.558 秒，单 worker 6.535 秒——并行反而慢了 16%。作者还是发布了这个并行化开关，并在发布时如实披露了数据。这篇 dev.to 文章记录了 Go 命令行日志查询工具 logq 在零依赖黑客松（Zero Dependency Hackathon）中的三个关键设计决定。

并行化：基准不支持的优化

logq 给最慢的查询路径加了 -j 标志并行到 8 个 goroutine，实测比单 worker 慢 16%。作者照常发布，原因在于：真实文件往往比测试文件大几个数量级，I/O 瓶颈场景下并行可能带来收益，单点基准不能代表全貌；同时 -j 默认关闭，不会伤害默认路径。作者把"基准不支持但我们还是发了"作为一个诚实的工程案例——发布优化时主动披露负向基准结果，而不是掩盖。

三值求值器：MISSING / null / false 三态

大多数查询工具把"这条记录没有该字段"和"该字段存在但是 JSON null"当成一回事，或者根本不想这个区别，直到一条形状不同的记录让整个运行崩溃。logq 把 MISSING、null、false 当作三个真正不同的状态贯穿整个求值器——这是项目历史上第一个真正的设计决定，早于 JSON 解码器和 CLI 的存在。

三态语义的实际效果：过滤器查询不会因为某条记录形状不同就半路崩溃；也永远不会悄悄告诉你 null "等于" missing——那种没有错误信息的错误答案是最糟的，因为没有任何东西提示你去检查。项目用三值真值表矩阵生成测试，覆盖所有比较操作。

用标准库替换 10420 个导入者的依赖

logq 用约 150 行代码实现于标准库 encoding/json 解码器之上，替换了 tidwall/gjson（10420 个已知导入者的流行 JSON 解析库）。对零依赖项目的构建原则来说，这是核心动作：去掉第三方依赖，用标准库完成同样的解析工作。

文中还引用了项目的依赖台账 STDLIB.md 的做法：整个台账以 git log 为证据链，逐条记录每个依赖决策的理由。作者在整篇文章中引用精确的 commit hash 和时间戳而非凭记忆描述，与项目自身的工程方式保持一致。

其他细节

项目在提交前两天的 CI 因一个从未完全诊断出的原因失败，作者选择移除 CI 而不是留一个无法解释的红徽章——把"不留未解释的失败状态"当作工程纪律。logq 是单静态二进制、零第三方依赖的 JSONL/logfmt/纯文本日志查询工具，支持过滤、分组、计数、百分位和时间窗口查询。

来源：We Shipped an Optimization Our Own Benchmark Said Not To - DEV Community