Flow 守卫式 match 的穷尽性实战：解析 `match_008_guard_exhaustiveness` 任务中的 guard 与穷尽检查协作

Flow 守卫式 match 的穷尽性实战：解析match_008_guard_exhaustiveness任务中的 guard 与穷尽检查协作

【免费下载链接】flowAdds static typing to JavaScript to improve developer productivity and code quality.项目地址: https://gitcode.com/gh_mirrors/flow30/flow

本篇技术指南围绕 Flow 官方 AI Evals 仓库（evals/README.md）中match_008_guard_exhaustiveness这一求值任务展开，剖析 Flow 的match表达式如何与守卫（guard）配合完成「按类别 + 价格阈值」的折扣计算，并解释为什么带守卫的分支不参与穷尽性计数、必须额外提供兜底分支。读完本文，你将掌握match表达式 +if守卫的完整写法、[match-not-exhaustive]错误的成因与修复方式，以及该任务在 AST 层面如何被自动评分验证。

一、任务速览：这个 eval 在考什么

match_008_guard_exhaustiveness位于求值目录 evals/evals/02_unique_features/match_008_guard_exhaustiveness/，属于「Flow 独有特性」类别，其 config.json 中标注的标签为flow、match、guards、exhaustiveness、pattern_matching，难度为hard。

任务的核心诉求（见 prompt.md）非常精炼：

• main.js定义了一个Item类型，包含name、price以及取值仅为'food'、'electronics'、'clothing'的category；
• 要求编写一个 Flow 函数discount(item: Item): number，用match表达式按类别和价格阈值施加折扣；
• 落入阈值以下的所有其他情况返回原价。

虽然任务描述刻意只描述「行为」而不指定「写法」（这是该 eval 平台的设计原则，见 evals/README.md 中「The prompt describes behavior, not the Flow syntax under test」），但评分器明确要求使用match表达式且每个用例必须带 guard，禁止使用switch。这决定了我们只能用 Flow 的match+ 守卫来实现。

二、需求建模：Item类型与三条折扣规则

先建立类型模型：

type Item = { name: string, price: number, category: 'food' | 'electronics' | 'clothing', };

这里的关键点在于category是一个字符串字面量联合类型（union of string literal types），它正好是match穷尽性检查的理想输入：Flow 可以枚举出所有可能取值。对应到本仓库官方文档，match对 disjoint object unions 的检查是明确支持的（见 website/docs/match/index.md 中的「Exhaustive Checking」一节）。

折扣规则按 prompt 原样复述：

注意「价格超过阈值」属于动态条件，它无法通过字面量模式表达（price是number，不是某个字面量），这正是 guard 的用武之地。

三、核心语法回顾：match 表达式与 guard

Flow 的match有两种形态：表达式与语句。本任务要求的是discount(item: Item): number返回number，因此使用match 表达式：每个用例的 body 是一个表达式，整个match的结果类型是所有用例表达式类型的联合（见 website/docs/match/index.md 中「Match Expressions」一节）。

基本结构：

const e = match (<arg>) { <pattern-1> => <expression-1>, <pattern-2> if (<cond>) => <expression-2>, <pattern-3> => <expression-3>, };

守卫（guard）的语义有两个关键点（同见 website/docs/match/index.md）：

1. 只有当模式本身匹配时，守卫表达式才会被求值；整个用例只有在「模式匹配且守卫结果为真」时才生效；
2. 守卫作用于整个模式，包括|或模式，例如1 | 2 if (cond)会先匹配1 | 2，再检查cond。

更重要的规则是：带守卫的用例不参与穷尽性检查计数。因为守卫可能为假，编译器无法保证该分支一定覆盖对应取值。这一点在官方文档中写得非常明确：Guarded cases do not count toward exhaustiveness checks, since they may or may not match based on the condition.

仓库测试 tests/match/expression.js 还展示了一个与本任务高度相关的细节：守卫可以细化与 match 参数无关的其他值，例如1 if (typeof y === 'number') => y as number。在我们的任务里，守卫条件直接引用item.price，正是这一能力的典型用法。

四、参考实现：两条等价的解法路线

有了上面的语法基础，实现discount有两种等价路线。

路线 A：直接对item.category做 match，守卫引用item.price

type Item = { name: string, price: number, category: 'food' | 'electronics' | 'clothing', }; function discount(item: Item): number { return match (item.category) { 'food' if (item.price > 50) => item.price * 0.9, 'electronics' if (item.price > 100) => item.price * 0.85, 'clothing' if (item.price > 75) => item.price * 0.8, _ => item.price, }; }

路线 B：对item整体做 match，用对象模式 + 变量声明模式提取price

function discount(item: Item): number { return match (item) { {category: 'food', price: const p} if (p > 50) => p * 0.9, {category: 'electronics', price: const p} if (p > 100) => p * 0.85, {category: 'clothing', price: const p} if (p > 75) => p * 0.8, _ => item.price, }; }

两种写法都满足评分要求：包含MatchExpression节点、每个用例带 guard、且没有switch。路线 A 更简短；路线 B 则演示了对象模式中const p的变量提取能力（对应官方文档 website/docs/match/patterns.md 中「Object patterns」的{prop: const x}语法）。

无论选哪条路线，最后都必须保留_兜底分支，原因见下一节。另外注意一个书写细节：match (arg) {的左花括号必须与参数在同一行，这是为了保证与旧的函数调用语法match(x);向后兼容（见 website/docs/match/index.md 的「Fine print」说明）。

五、为什么兜底分支是必须的：guard 不参与穷尽性计数

这是本任务命名为guard_exhaustiveness的核心考点。删掉_分支后：

return match (item.category) { 'food' if (item.price > 50) => item.price * 0.9, 'electronics' if (item.price > 100) => item.price * 0.85, 'clothing' if (item.price > 75) => item.price * 0.8, // ERROR [match-not-exhaustive] };

Flow 会报[match-not-exhaustive]错误。原因是：item.category的输入类型是'food' | 'electronics' | 'clothing'，虽然每个类别都写了模式，但这些模式全部带守卫——守卫可能为假（例如一件 $20 的食品），因此 Flow 无法确认这些取值被覆盖，只能要求一个无条件匹配的兜底分支。

仓库中 tests/match_exhaustive/guards.js 用大量用例精确验证了这一语义，例如（节选自「Basic」一节）：

declare const x: 1 | 2; match (x) { // ERROR: missing `1` 1 if (cond) => {} 2 => {} } match (x) { // OK：带守卫的 `1` 之后补一个不带守卫的 `1` 1 if (cond) => {} 1 => {} 2 => {} }

第一段说明「仅带守卫的1」不足以覆盖1；第二段说明「守卫用例 + 普通用例」组合起来才算覆盖。这与我们任务中「守卫用例 +_兜底」的组合完全同构。

_（通配符模式）匹配一切（见 website/docs/match/patterns.md 中「Wildcard patterns」），因此它能兜住「类别匹配但价格未达阈值」的所有剩余情况——这正是 prompt 中「All other items return their original price」的语义。通配符还有一种替代写法是变量声明模式const x（两者都匹配一切，见 website/docs/match/index.md）。

反向的「unused pattern」检查也值得注意：一旦某取值已被前面的无条件用例覆盖，后面的重复模式会被标记为冗余。例如 tests/match_exhaustive/guards.js 中：

match (x) { // OK 1 => {} 1 if (cond) => {} // ERROR：unused pattern 2 => {} }

因此守卫用例必须排在其对应无守卫用例之前。而 tests/match_exhaustive/guards.js 的「Wildcards」一节还验证了「带守卫的通配符不算覆盖」：对string类型的输入，_ if (cond) => {}单独出现会被报「missing_」，必须再补一个无守卫的_。

此外，match语句场景下同样遵循该语义：tests/match/statement.js 中「Throws in guards」一段展示了即使守卫if (invariant(false))恒为假（恒抛出），match 之后的代码也不算不可达——因为守卫可能为假，分支可能不匹配。这从另一个角度印证了「守卫 = 不确定匹配」这一心智模型。

六、AST 级自动评分：求值器如何确认你用了 match + guard

本任务所在的 eval 平台采用 SWE-bench 风格：compile_swebench.py对input/与ideal/做 diff 生成 gold patch 与评分脚本，run_swebench.py在临时工作目录中应用补丁并运行评分器（见 evals/README.md）。本任务在 config.json 中自定义了三个 AST 级评分器：

"grading": { "graders": [ { "type": "contains_ast_node_type", "query": "MatchExpression" }, { "type": "ast_query", "selector": ".type == \"MatchExpressionCase\" and .guard" }, { "type": "contains_ast_node_type", "query": "SwitchStatement", "negate": true } ] }

逐一解读：

1. 必须出现MatchExpression节点：证明你确实用了match，而不是其他条件结构；
2. 至少一个MatchExpressionCase带.guard：证明你使用了守卫语法（这是guard_exhaustiveness的题眼）；
3. 禁止出现SwitchStatement（negate）：防止你用switch绕过match作答。

评分器通过flow ast输出 AST 再交给jq断言结构（见 evals/README.md 的「Grading」一节）。这意味着即使代码能通过类型检查，只要没用match+ guard，评分依然会失败。在本地验证时，可以运行make validate ARGS="--eval match_008_guard_exhaustiveness"让平台应用参考解法并跑通全部评分器（无需调用任何模型）。

七、常见错误与调试指引

把上述讨论整理成一份速查表，方便排查问题：

最后补充启用条件：pattern_matching配置项控制match的开关，自 Flow v0.317 起默认开启（true）；更早版本需要在.flowconfig的[options]下显式添加pattern_matching=true。该配置项在 website/docs/config/options.md 中有完整说明。你可以在本仓库的 tests/match/ 与 tests/match_exhaustive/ 目录下看到大量可直接运行的测试样例，例如 tests/match_exhaustive/basic.js（字面量/布尔/可空类型穷尽性）、tests/match/matching.js（对象/元组/联合匹配）以及 tests/match_exhaustive/exhaustive-error-message.js（错误消息格式），它们是学习match语义最直接的第一手素材。

【免费下载链接】flowAdds static typing to JavaScript to improve developer productivity and code quality.项目地址: https://gitcode.com/gh_mirrors/flow30/flow