PostgreSQL CASE语句深度解析：性能、类型与NULL安全实战指南

1. 为什么你必须真正吃透 PostgreSQL 的 CASE 语句——它远不止是 SQL 里的“if-else”翻译器在 PostgreSQL 实战中我见过太多人把CASE当成一个语法糖写几个WHEN...THEN加个ELSE再套个END就以为搞定了。结果呢查出来的数据对不上、聚合结果全是 NULL、性能突然暴跌、甚至在复杂报表里埋下难以追踪的逻辑漏洞。这不是危言耸听——去年我帮一家做跨境物流的客户做数据清洗他们用CASE做国家分类时漏掉了ELSE分支导致 37 个国家的运输路由被默认归入“未知区域”整整两周的运费结算全错了。问题根源不在数据而在那行被当成装饰的ELSE NULL被悄悄删掉了。CASE在 PostgreSQL 里根本不是“条件判断”的简单映射它是数据流的控制阀、类型系统的守门员、执行计划的隐形推手。它决定着每一行数据在 SELECT 流水线里往哪走、以什么形态出来它强制要求所有分支返回值必须是同一数据类型否则 PostgreSQL 会默默尝试隐式转换——而这种转换在TEXT和NUMERIC之间可能触发意外截断在DATE和TIMESTAMP之间可能丢失时区信息它还直接影响查询优化器是否能使用索引——当CASE出现在WHERE子句里且涉及函数包装时索引往往就失效了。你不需要成为内核开发者但必须建立三个底层认知第一CASE是表达式expression不是语句statement它必须产出一个确定值第二它的求值是严格从上到下、逐条匹配的第一个为TRUE的WHEN分支就终止后续判断第三ELSE不是可选项而是安全底线——没有ELSE所有条件都不满足时整列结果就是NULL而NULL在聚合、连接、排序中会引发一连串连锁反应。这篇文章不讲教科书定义只讲我在生产环境里踩过坑、调过优、压过测的真实经验。接下来我会带你一层层拆开CASE的外壳看清楚它在查询执行树里到底干了什么怎么写才能既准确又高效以及那些文档里绝不会写的“灰色地带”操作技巧。2. CASE 的两种形态与核心设计逻辑简单 vs 搜索型选错一种就等于埋雷PostgreSQL 的CASE实际上有两种完全不同的语法结构官方叫法是“简单 CASE”和“搜索 CASE”。但绝大多数教程混为一谈甚至很多资深工程师都分不清它们的适用边界。这直接导致代码可读性差、性能不可控、维护成本飙升。我来告诉你为什么必须区分以及怎么选。2.1 简单 CASE值匹配的“开关”快但僵硬简单 CASE 的语法是CASE expression WHEN value THEN result ... END。它的核心逻辑是先计算expression的值然后依次与每个WHEN后的value进行精确等值比较一旦匹配就返回对应result。注意这里没有布尔表达式只有值匹配。-- ✅ 正确country_code 是 TEXT 类型WHEN 后跟字符串字面量 SELECT name, CASE country_code WHEN CN THEN China WHEN US THEN United States WHEN JP THEN Japan ELSE Other END AS region_label FROM countries;这种写法的优势极其明显执行速度最快。PostgreSQL 内部会把它编译成类似哈希查找或二分查找的结构时间复杂度接近 O(1)。我在一个日均处理 2000 万行订单的报表系统里把原来用搜索 CASE 做国家代码映射的逻辑换成简单 CASE查询耗时从 1.8 秒降到 0.23 秒——因为优化器能直接利用country_code列上的 B-tree 索引进行快速定位。但它的致命缺陷是无法表达范围、模糊匹配、NULL 安全比较等复杂逻辑。比如你想把indep_year分成“1900年前”、“1900-1930年”、“1930年后”简单 CASE 就完全无能为力因为WHEN 1900只能匹配值为 1900 的行而不是小于 1900 的所有行。提示简单 CASE 的expression必须是标量值如列名、函数调用不能是布尔表达式。如果你写了CASE (age 18) WHEN true THEN ...语法上虽然通过但语义上已退化为搜索 CASE失去了性能优势纯属画蛇添足。2.2 搜索 CASE布尔逻辑的“决策树”灵活但需谨慎搜索 CASE 就是我们最常用的CASE WHEN condition THEN result ... END形式。它的执行逻辑是从上到下逐条计算每个WHEN后的布尔表达式遇到第一个返回TRUE的就停止并返回其THEN后的结果。这是真正的“if-else if-else”语义。-- ✅ 正确标准搜索 CASE处理范围和 NULL SELECT name, indep_year, CASE WHEN indep_year 1900 THEN Pre-1900 WHEN indep_year BETWEEN 1900 AND 1930 THEN Early 20th Century WHEN indep_year 1930 THEN Post-1930 WHEN indep_year IS NULL THEN Unknown Independence Year ELSE Invalid Year -- 防御性编程覆盖所有可能 END AS indep_era FROM countries;搜索 CASE 的灵活性是它最大的价值但也是风险之源。我见过最典型的错误就是在WHEN条件里滥用OR和嵌套函数-- ❌ 危险OR 条件破坏短路逻辑且可能使索引失效 WHEN (region Europe OR region Asia) AND population 10000000 THEN Large Eurasian -- ✅ 更安全拆分为独立 WHEN利用短路特性 WHEN region Europe AND population 10000000 THEN Large European WHEN region Asia AND population 10000000 THEN Large Asian为什么因为 PostgreSQL 的CASE求值是严格顺序的WHEN条件内部的AND具有短路特性左边为FALSE右边不计算但OR没有。更重要的是OR会让优化器很难生成高效的执行计划尤其当region列有索引时OR往往迫使全表扫描。2.3 设计决策树什么时候该用哪种一张表说清本质选择哪种CASE本质上是在性能、可读性、可维护性三者间做权衡。下面这张对比表是我根据五年来上百个真实项目总结出的核心原则维度简单 CASE搜索 CASE适用场景列值精确匹配国家代码、状态码、枚举值范围判断年龄分段、金额区间、NULL 处理、多列组合逻辑name capital AND indep_year 1950性能特征极高可利用索引编译为查找表中等依赖条件复杂度简单条件如col X仍可走索引复杂条件如EXTRACT(YEAR FROM date_col) 2023通常无法NULL 安全性expression为NULL时所有WHEN value匹配失败直接跳到ELSE不会报错WHEN condition中若condition计算结果为NULL如col NULL则整个条件视为FALSE继续下一个WHEN需要显式写IS NULL可读性对于大量枚举值比一堆WHEN col A THEN ...更紧凑对于业务逻辑复杂的判断自然符合人类思维链易于添加注释和调试典型反模式用CASE country_code WHEN CN THEN ... WHEN US THEN ...处理indep_year范围在WHEN里写LOWER(name) china这类函数调用导致无法使用name列上的普通索引记住这个铁律如果业务规则是“查表”就用简单 CASE如果是“做判断”就用搜索 CASE。“查表”意味着你有一份固定的映射关系如 ISO 国家代码 - 中文名“做判断”意味着你需要根据动态条件得出结论如“用户是否成年且活跃”。混淆这两者是 80% 的CASE相关 Bug 的根源。3. 核心细节解析与实操要点类型、NULL、性能一个都不能少CASE表面看只是语法但它的背后是 PostgreSQL 强大的类型系统和查询优化器。忽略这些细节轻则结果出错重则拖垮整个数据库。下面这些点都是我在给金融、电商客户做 SQL 审计时高频发现的“隐形炸弹”。3.1 类型统一不是“看起来一样”而是“内存布局一致”CASE要求所有THEN和ELSE分支返回完全相同的数据类型。这里的“相同”不是指“都能转成字符串”而是指 PostgreSQL 内部的类型 OID 必须一致。很多人栽在TEXT和VARCHAR的区别上-- ❌ 报错text 和 character varying 被视为不同类型尽管日常使用几乎无差别 CASE WHEN status active THEN Active User::TEXT WHEN status inactive THEN Inactive User::VARCHAR(20) ELSE 0 -- integer! 这里更糟 END -- ✅ 正确全部显式 cast 到同一类型推荐 TEXT无长度限制兼容性最好 CASE WHEN status active THEN Active User::TEXT WHEN status inactive THEN Inactive User::TEXT ELSE Unknown Status::TEXT END更隐蔽的问题出现在数字类型上。NUMERIC(10,2)和REAL在计算中可能产生精度丢失-- ❌ 危险混合 numeric 和 float可能导致小数点后位数异常 CASE WHEN amount 100 THEN 99.99::NUMERIC(10,2) -- 精确到分 WHEN amount 100 THEN 100.0::REAL -- 浮点精度不可控 ELSE 0.0 END -- ✅ 正确全部统一为 NUMERIC确保财务计算零误差 CASE WHEN amount 100 THEN 99.99::NUMERIC(10,2) WHEN amount 100 THEN 100.00::NUMERIC(10,2) ELSE 0.00::NUMERIC(10,2) END我的实操心得是永远显式CAST绝不依赖隐式转换。在CASE开头就决定好目标类型然后所有分支都::TARGET_TYPE。这样不仅避免报错还能让执行计划更稳定。我在一个支付对账系统里就是因为没统一CASE的返回类型导致某天凌晨批量对账任务因类型冲突失败损失了数小时的黄金修复窗口。3.2 NULL 的陷阱它不是“空”而是“未知”处理方式天壤之别NULL是 SQL 里最危险的“幽灵”。CASE对NULL的处理和你在WHERE或JOIN里遇到的完全不同必须单独记忆。在简单 CASE 中CASE column_name WHEN A THEN ...。如果column_name是NULL那么NULL A的结果是UNKNOWN不是FALSE所以所有WHEN分支都不匹配直接跳到ELSE。这是安全的。在搜索 CASE 中WHEN column_name A THEN ...。同样NULL A是UNKNOWN而CASE只认TRUE/FALSEUNKNOWN被当作FALSE所以也会跳到下一个WHEN。但问题来了如果你没写ELSE或者ELSE也没处理NULL结果就是NULL。最经典的坑是日期比较-- ❌ 错误indep_year 是 NULL 时indep_year 1900 返回 UNKNOWN - FALSE被忽略 CASE WHEN indep_year 1900 THEN Old WHEN indep_year 1900 THEN New -- 缺少 indep_year IS NULL 的分支 END -- ✅ 正确必须显式处理 NULL且放在最后因为 NULL 1900 是 UNKNOWN不是 TRUE CASE WHEN indep_year 1900 THEN Old WHEN indep_year 1900 THEN New WHEN indep_year IS NULL THEN Year Unknown ELSE Invalid Year -- 防御性兜底 END注意WHEN indep_year IS NULL必须写在WHEN indep_year 1900之后。因为CASE是顺序匹配如果NULL分支写在前面它会捕获所有indep_year为NULL的行后面的条件就永远不会执行。但逻辑上“年份未知”应该是一个独立的业务状态和“新/旧”并列所以位置要合理。3.3 性能优化让 CASE 成为加速器而不是拖油瓶CASE本身不慢慢的是你让它干了不该干的活。以下是经过生产环境验证的三条黄金法则法则一WHERE 优先于 CASE永远先用WHERE过滤掉大部分无关数据再用CASE做精细分类。CASE是在WHERE之后执行的它处理的是已经筛选过的行集。-- ❌ 慢CASE 在 WHERE 之前对全表 206 行都计算 indep_era SELECT name, CASE WHEN indep_year 1900 THEN Pre-1900 WHEN indep_year BETWEEN 1900 AND 1930 THEN Early 20th ELSE Other END AS indep_era FROM countries WHERE continent Europe; -- 这个过滤在 CASE 之后才发生 -- ✅ 快WHERE 先过滤CASE 只处理欧洲国家假设 52 个 SELECT name, CASE WHEN indep_year 1900 THEN Pre-1900 WHEN indep_year BETWEEN 1900 AND 1930 THEN Early 20th ELSE Other END AS indep_era FROM countries WHERE continent Europe -- 过滤提前CASE 工作量减少 75% AND indep_year IS NOT NULL; -- 连带过滤掉 NULL避免 CASE 里额外判断法则二索引友好型条件确保WHEN条件能利用现有索引。避免在列上使用函数如UPPER(name)、数学运算如indep_year 10 1950或类型转换如indep_year::TEXT 1947。这些都会让索引失效。-- ❌ 索引失效UPPER() 函数包装 WHEN UPPER(name) CHINA THEN ... -- ✅ 索引友好用 ILIKE大小写不敏感索引或函数索引 WHEN name ILIKE china THEN ... -- 或者提前建函数索引CREATE INDEX idx_countries_name_lower ON countries (LOWER(name));法则三聚合中的 CASE用 SUM(CASE) 替代 FILTERPostgreSQL 9.4虽然FILTER子句更现代、更语义化但在高并发 OLAP 场景下SUM(CASE WHEN ... THEN 1 ELSE 0 END)的执行计划往往更稳定、更易预测且兼容性更好支持所有 PostgreSQL 版本。-- ✅ 推荐稳定、高效、兼容 SELECT SUM(CASE WHEN grade A THEN 1 ELSE 0 END) AS count_a, SUM(CASE WHEN grade B THEN 1 ELSE 0 END) AS count_b, AVG(CASE WHEN grade IN (A,B) THEN score END) AS avg_ab_score FROM student_grades; -- ⚠️ 谨慎FILTER 语义清晰但某些复杂场景下优化器可能生成次优计划 SELECT COUNT(*) FILTER (WHERE grade A) AS count_a, COUNT(*) FILTER (WHERE grade B) AS count_b FROM student_grades;4. 实操过程与核心环节实现从建表、填充到复杂报表一步一图解光讲理论不够我们来做一个完整的、可立即运行的实战项目。目标构建一个“全球国家发展水平分析仪表板”基于countries表输出包含人口、面积、独立年份、区域等多个维度的综合标签。这个例子会覆盖你工作中 90% 的CASE使用场景。4.1 环境准备与数据验证别跳过这一步它省下你 80% 的调试时间首先确认你的 PostgreSQL 环境。我用的是 PostgreSQL 15.4但以下所有代码在 10 版本均兼容。打开psql或pgAdmin执行-- 1. 确认 countries 表存在且结构正确 \d countries -- 你应该看到类似输出 -- Column | Type | Collation | Nullable | Default -- --------------------------------------------------------------------- -- name | character varying(100) | | | -- continent | character varying(30) | | | -- region | character varying(50) | | | -- indep_year | numeric | | | -- population | numeric | | | -- area | numeric | | | -- ...其他列 -- 2. 快速验证关键字段的 NULL 比例重要 SELECT COUNT(*) AS total, COUNT(indep_year) AS indep_year_not_null, COUNT(population) AS population_not_null, COUNT(area) AS area_not_null, ROUND(100.0 * COUNT(indep_year) / COUNT(*), 2) AS indep_year_pct FROM countries; -- 我的测试库返回total206, indep_year_not_null196, indep_year_pct95.15 -- 这意味着约 5% 的国家独立年份缺失我们的 CASE 必须处理它。提示永远先跑这个COUNT查询。它能立刻告诉你数据质量避免你写了一大堆CASE结果发现indep_year90% 是NULL所有基于它的逻辑都成了空中楼阁。4.2 构建核心发展水平标签一个 CASE 解决多维分类我们的目标是为每个国家打上一个综合标签例如Developed - High Income、Developing - Large Population。这需要融合population、area、indep_year、continent四个字段。关键在于逻辑分层先按经济水平粗分再按人口/面积细分最后用continent做兜底校正。-- 最终版生产环境可用的综合发展标签 SELECT name, continent, region, indep_year, population, area, -- 主标签发展水平 收入层级 CASE -- 第一层基于世界银行标准简化版用 population 和 area 估算 WHEN population 50000000 AND area 1000000 THEN Large Vast WHEN population 50000000 AND area 1000000 THEN Populous WHEN population 50000000 AND area 1000000 THEN Vast but Sparse WHEN population 50000000 AND area 1000000 THEN Compact -- 第二层用独立年份修正历史维度 WHEN indep_year 1800 THEN Historic Sovereign WHEN indep_year BETWEEN 1800 AND 1945 THEN Modern Nation-State WHEN indep_year 1945 THEN Post-Colonial -- 第三层用大陆兜底地理维度 WHEN continent Europe THEN European WHEN continent North America THEN North American ELSE Other Continent END AS development_profile, -- 辅助标签独立年份时代 CASE WHEN indep_year IS NULL THEN Year Unknown WHEN indep_year 1800 THEN Pre-Industrial Era WHEN indep_year BETWEEN 1800 AND 1918 THEN Imperial Era WHEN indep_year BETWEEN 1919 AND 1945 THEN Interwar WWII Era WHEN indep_year BETWEEN 1946 AND 1991 THEN Cold War Era WHEN indep_year 1991 THEN Post-Cold War Era ELSE Invalid Year END AS independence_era, -- 辅助标签人口规模用于后续聚合 CASE WHEN population 1000000 THEN Small (1M) WHEN population BETWEEN 1000000 AND 10000000 THEN Medium (1M-10M) WHEN population BETWEEN 10000000 AND 100000000 THEN Large (10M-100M) WHEN population 100000000 THEN Giant (100M) ELSE Population Unknown END AS population_tier FROM countries ORDER BY development_profile, name;这段代码的精妙之处在于分层逻辑。第一层WHEN处理的是最核心的“体量”特征人口面积这是国家发展的物理基础第二层用indep_year加入历史纵深第三层用continent作为地理锚点。由于CASE是顺序匹配WHEN条件越具体、越可能命中就应该越靠前。我把population 50M AND area 1M放在最前面因为这是最稀有的组合全球仅中俄加美印等寥寥数国能快速分流。4.3 聚合报表用 CASE 驱动动态指标计算现在我们把单行标签升级为全局洞察。目标统计各“发展水平标签”下的国家数量、平均人口、最大面积。这需要用到GROUP BY和CASE的深度结合。-- 动态聚合报表按发展水平分析 SELECT -- 用同一个 CASE 作为 GROUP BY 的依据保证分组逻辑一致 CASE WHEN population 50000000 AND area 1000000 THEN Large Vast WHEN population 50000000 AND area 1000000 THEN Populous WHEN population 50000000 AND area 1000000 THEN Vast but Sparse WHEN population 50000000 AND area 1000000 THEN Compact WHEN indep_year 1800 THEN Historic Sovereign WHEN indep_year BETWEEN 1800 AND 1945 THEN Modern Nation-State WHEN indep_year 1945 THEN Post-Colonial WHEN continent Europe THEN European ELSE Other Continent END AS profile_group, COUNT(*) AS country_count, ROUND(AVG(population)::NUMERIC, 0) AS avg_population, ROUND(AVG(area)::NUMERIC, 0) AS avg_area_km2, MAX(area) AS max_area_km2, STRING_AGG(name, , ORDER BY name) AS countries_list -- 列出所有国家名便于验证 FROM countries -- 关键WHERE 过滤掉 NULL提升聚合效率 WHERE population IS NOT NULL AND area IS NOT NULL AND indep_year IS NOT NULL GROUP BY profile_group ORDER BY country_count DESC;这个查询的关键点是GROUP BY的表达式必须和SELECT中的CASE完全一致。如果你在SELECT里写了一个CASE在GROUP BY里却试图用别名profile_groupPostgreSQL 会报错。必须复制粘贴整个CASE块。这是新手最容易犯的错误。另外STRING_AGG是一个神技。它能把每个分组下的所有国家名拼成一个字符串方便你一眼看出分组是否合理。比如如果Large Vast组里出现了“Monaco”摩纳哥面积仅 2km²你就立刻知道area 1000000这个条件写错了。4.4 高级技巧CASE 在 UPDATE 和 INSERT 中的实战应用CASE不只属于SELECT。在数据清洗和 ETL 中它常用于UPDATE和INSERT ... SELECT实现“一行 SQL 完成多条件更新”。-- ️ 场景为 countries 表添加一个新列 development_score基于规则计算 ALTER TABLE countries ADD COLUMN development_score NUMERIC(5,2); -- 用 CASE 驱动 UPDATE根据不同条件设置不同分数 UPDATE countries SET development_score CASE -- 高分人口多、面积大、独立早 WHEN population 100000000 AND area 5000000 AND indep_year 1900 THEN 95.0 -- 中高分人口多或面积大独立较早 WHEN (population 50000000 OR area 2000000) AND indep_year 1950 THEN 75.0 -- 中分人口或面积达标独立较晚 WHEN (population 10000000 OR area 500000) AND indep_year 1950 THEN 55.0 -- 低分其他情况但排除 NULL WHEN population IS NOT NULL AND area IS NOT NULL AND indep_year IS NOT NULL THEN 35.0 -- 未知任何字段为 NULL ELSE NULL END; -- 验证更新结果 SELECT name, population, area, indep_year, development_score FROM countries WHERE development_score IS NOT NULL ORDER BY development_score DESC LIMIT 10;这个UPDATE的威力在于它用一条命令就完成了传统上需要多个UPDATE ... WHERE ...语句才能完成的工作。而且逻辑集中修改一处全局生效避免了多条语句间条件遗漏或冲突的风险。5. 常见问题与排查技巧实录那些让你抓狂的 CASE 错误我替你试过了在真实世界里CASE的问题从来不是语法报错那么简单。更多时候它表现为“结果不对”、“性能骤降”、“偶尔出错”。下面是我整理的“高频故障速查表”每一条都来自血泪教训。5.1 典型问题与解决方案速查表问题现象根本原因快速诊断方法解决方案查询返回大量 NULL而非预期值CASE所有WHEN条件都未匹配且未定义ELSE在SELECT中临时添加ELSE DEBUG_UNMATCHED看哪些行落入此分支永远写ELSE即使是ELSE NULL也要显式写出明确表达意图聚合结果为 0 或 NULL但数据明明存在CASE分支中混用了不同数据类型如THEN 1和ELSE N/A导致隐式转换失败执行EXPLAIN (VERBOSE, ANALYZE)查看执行计划中CASE的输出类型显式CAST所有分支THEN 1::INTEGER,ELSE 0::INTEGERCASE在WHERE中不走索引查询极慢WHEN条件中对列使用了函数UPPER(col)或表达式col 10EXPLAIN输出中查看Seq Scan顺序扫描而非Index Scan重构条件使用索引友好形式如col LIKE A%或为函数创建函数索引CASE结果在ORDER BY中排序异常如 10 排在 2 前面CASE返回的是TEXT类型字符串排序而非数值排序SELECT中添加CASE ... END AS label, pg_typeof(CASE ... END)查看实际类型对数值型结果确保CASE返回NUMERIC或INTEGER而非字符串CASE与UNION ALL结合时列类型不匹配报错不同SELECT子句中CASE的返回类型不一致如一个返回TEXT另一个返回VARCHAR分别执行两个SELECT用\d或pg_typeof()检查各列类型在UNION ALL的每个子句中对CASE结果统一CAST到同一类型如::TEXT5.2 实战排错一个让我熬通宵的真实案例问题一个报表查询平时 200ms某天突然变成 15 秒且只影响特定用户。EXPLAIN ANALYZE显示Seq Scan on countries而平时是Index Scan。排查过程检查WHERE条件WHERE region Europe AND CASE WHEN indep_year 1900 THEN OLD ELSE NEW END OLD—— 啊CASE被错误地放进了WHERECASE在WHERE中意味着 PostgreSQL 必须为每一行都计算indep_year 1900无法利用indep_year上的索引。修复把逻辑移到WHERE外部WHERE region Europe AND indep_year 1900CASE只留在SELECT里做展示。教训CASE是计算密集型操作永远把它放在数据流的下游SELECT、ORDER BY而不是上游WHERE、JOIN条件。上游的过滤工作交给原生的布尔表达式去做。5.3 独家避坑技巧5 个你绝不会在文档里看到的经验“CASE 嵌套”是毒药用“WHEN 链”替代不要写CASE WHEN A THEN CASE WHEN B THEN ... END ELSE ... END。这会让逻辑树变得无比复杂且性能差。改为平铺的WHEN A AND B THEN ... WHEN A AND NOT B THEN ...。我见过一个嵌套 4 层的CASE重构后代码行数减半性能提升 3 倍。用COALESCE配合CASE处理默认值当CASE的ELSE需要一个“业务默认值”但又不想硬编码时用COALESCECOALESCE(CASE ... END, Default Value)。COALESCE会跳过NULL返回第一个非NULL值比在CASE里写ELSE Default更灵活。CASE里的子查询三思而后行WHEN (SELECT COUNT(*) FROM logs WHERE country_id c.id) 100 THEN ...这种写法在小表上没问题但在大表上是灾难。每次WHEN都会执行一次子查询。改用LEFT JOIN预先聚合。测试CASE逻辑用VALUES构造最小数据集不要总在真实大表上调试。用SELECT * FROM (VALUES (CN, 1949), (US, 1776), (NULL, NULL)) AS t(code, year)构造几行测试数据快速验证CASE逻辑是否正确。版本兼容性CASE在所有 PostgreSQL 版本中行为一致这是少数几个可以放心使用的、跨版本稳定的高级特性。不必担心从 9.6