企业官网建设流程全解析

ESLint no-unexpected-multiline 规则详解：捕获看似换行结束实则未结束的混淆多行表达式

【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint

导读

no-unexpected-multiline是 ESLint 内置的一条problem（问题）类型规则，用于识别"换行看起来结束了语句、但实际上并没有结束"的混淆多行表达式——这类代码在语法上完全合法，却极可能让读者误判语句边界，进而在运行时抛出异常。本文以 官方规则文档 为骨架，结合 规则源码 与 完整测试用例，系统讲解该规则的背景原理、四种检测场景、配置方式与适用边界，帮助你理解并驾驭这条已进入recommended集合的默认开启规则。

背景：JavaScript 的自动分号插入（ASI）与歧义换行

JavaScript 中分号通常可以省略，因为引擎会执行自动分号插入（Automatic Semicolon Insertion，简称 ASI）。如果你希望强制或禁止分号，可以使用 semi 规则。

ASI 的规则本身相对直接。正如 Isaac Schlueter 曾总结的那样：换行符总是会结束一条语句，其效果等同于分号，除非满足以下任一例外：

• 语句中存在未闭合的括号、数组字面量、对象字面量，或者以其他无法合法结束语句的方式结尾（例如以.或,结尾）；
• 该行是--或++（此时它会作用于下一行的 token，执行自减/自增）；
• 该行是for()、while()、do、if()或else，且后面没有{；
• 下一行以[、(、+、*、/、-、,、.或其他只能出现在单个表达式中两个 token 之间的二元运算符开头。

在"换行不会结束语句"的这些例外情况下，如果程序员漏写了分号，两条本不相关的连续代码行就会被解析器合并成同一个表达式。这种代码虽然在语法上是合法的（能通过解析），但语义与书写者的意图完全不同——尤其是在"无分号"的编码风格下，读者很容易忽略这个笔误，导致代码在运行时抛出异常。

Rule Details：规则如何判定"意外的多行表达式"

本规则的核心定义是：禁止那些"换行看起来像在结束语句，但实际上并没有"的混淆多行表达式。它在 规则元信息 中声明为：

• type: "problem"：属于问题类规则，意味着发现的问题通常是真正的 bug 隐患；
• recommended: true：已列入 ESLint 的推荐配置eslint:recommended，默认开启（conf/rules.json 数据 也确认其为 recommended 且不可自动修复fixable: false）；
• schema: []：不接受任何选项；
• 四条消息 ID：function、property、taggedTemplate、division，分别对应规则检测的四类场景。

检测场景一：函数调用前的换行（(开头）

当上一行的语句（如变量声明const foo = bar）之后紧跟一行以(开头的函数调用时，ASI 不会插入分号，两行会被合并为一个表达式。源码中通过 CallExpression 分支 检查：若调用表达式的callee与参数开括号之间存在换行，即报告function消息。

错误示例：

/*eslint no-unexpected-multiline: "error"*/ const foo = bar (1 || 2).baz(); // 被解析为 bar(1 || 2).baz() 而非两条语句

正确示例：

const foo = bar; (1 || 2).baz(); // 显式分号结束上一条语句 const baz = bar ;(1 || 2).baz() // 行首分号强制结束语句

检测场景二：属性访问前的换行（[开头）

当下一行以[开头时，解析器会把它视为对上一行表达式的计算属性访问，而不是数组字面量。源码中的 MemberExpression 分支 专门针对计算属性（node.computed为真）且非可选链（node.optional为假）的成员表达式做换行检查，命中后报告property消息。

错误示例：

const hello = 'world' [1, 2, 3].forEach(addNumber); // 被解析为 'world'[1,2,3] 再调用，抛出异常

正确示例：

const hello = 'world'; [1, 2, 3].forEach(addNumber); const hi = 'world' void [1, 2, 3].forEach(addNumber); // 用 void 运算符隔断表达式

检测场景三：标签模板前的换行（`开头）

当上一行是一个函数表达式、变量声明等，下一行以反引号开头的模板字符串开始时，该模板串会被解析为标签模板（tagged template），即调用上一行的函数。源码中的 TaggedTemplateExpression 分支 检查模板quasi前的 token 与模板起始位置是否跨行，命中即报告taggedTemplate消息。该分支还专门处理了常见标签、括号包裹的标签以及 TypeScript 泛型类型参数等情况。

错误示例：

const x = function() {} `hello` // 被解析为调用 x`hello` const y = function() {} y `hello` // 跨两行后依然被视为 y`hello`

正确示例：

const x = function() {}; `hello` // 分号结束语句，模板串成为独立表达式 const tag = function() {} tag `hello` // 有意使用标签模板，属于合法用法

检测场景四：除法运算符前的换行（/开头）

当上一行以变量名等表达式结尾、下一行以/开头的正则字面量开始时，整段代码会被解析为连续除法运算而非两条语句。源码中的 BinaryExpression 分支 做了精细的判别：通过正则REGEX_FLAG_MATCHER = /^[gimsuy]+$/u匹配/之后的 token 是否为合法的正则修饰符，从而确认下一行确实是一个正则字面量，再报告division消息。

错误示例：

const z = foo /regex/g.test(bar) // 被解析为连续除法 foo / regex / g / .test(bar)

正确示例（分隔除法表达式，避免歧义）：

const z = foo / 2;

Options：无选项配置

本规则没有任何选项（schema: []，见 规则源码）。你只能选择开启或关闭它，无法调整检测的严格程度或范围。

作为对比，semi规则（强制/禁止分号）与no-unexpected-multiline是两条独立的规则——需要注意：被本规则视为问题的这些模式，semi规则并不会标记出来。即便你已经通过semi规则统一了分号风格，no-unexpected-multiline依然有独立的存在价值，二者互为补充。

使用方式与配置示例

在 ESLint 扁平配置（flat config）中开启本规则：

export default [ { rules: { "no-unexpected-multiline": "error", }, }, ];

由于该规则已在recommended: true中，直接继承eslint:recommended即可默认启用。实际检查时，ESLint 通过 lib/rules/index.js 中的"no-unexpected-multiline": () => require("./no-unexpected-multiline")注册并惰性加载该规则模块。如需手动验证，也可以在仓库根目录下对示例文件运行：

node bin/eslint.js --no-config-lookup --rule 'no-unexpected-multiline: error' example.js

边界情况与源码级细节

从 规则测试用例 可以看到，规则在大量边界场景下做了严谨处理：

• 可选链不误报：var a = b\n ?.(x || y).doSomething()以及?.[形式均判为合法，因为?.已经明确表达了跨行继续的意图（对应源码中node.optional的过滤）；
• 未闭合表达式不误报：var a = (\n(123)\n)、f(\n(x)\n)等带未闭合括号的多行写法是合法代码；
• 类字段（Class Fields）场景：ES2015+ 的类字段与计算属性名之间允许换行，class C { field1\n[field2]; }是合法的，但class C { field1 = obj\n[field2]; }会触发property报告，因为字段初始化表达式与计算属性之间形成了意外合并；
• 除法的精细判别：foo\n/ bar /2这类写法不会误报（2不是正则修饰符），而foo\n/ bar /gym、foo\n/ bar /s.test(baz)等会被判定为混淆除法并报告division；测试中还有专门针对 TypeScript 泛型标签模板（issue #11650 相关）的 parser fixture 用例。

此外，func-call-spacing 的源码注释指出："如果存在?.，它并不会隐藏 no-unexpected-multiline 的错误"，说明可选链语法与换行检测之间存在经过深思熟虑的交互设计，两条规则各司其职。

When Not To Use It：何时关闭本规则

如果你非常确信自己不会意外写出这类代码，可以关闭此规则。但需要记住，这类问题代码是语法正确的，解析器不会报错，semi规则也不会介入，因此它属于"沉默的 bug"——通常在运行时才会暴露。对于绝大多数项目，保留eslint:recommended中该规则的默认开启状态是更稳妥的选择。

总结

no-unexpected-multiline用四条针对性检测（函数调用、属性访问、标签模板、除法/正则混淆）覆盖了 ASI 例外规则下最容易产生的四类"换行歧义"问题。它无选项、不可自动修复、已被推荐配置默认启用，其实现细节（可选链过滤、类字段兼容、正则修饰符判别）均可在 规则源码 与 测试套件 中逐一验证。理解它的判定逻辑，能帮助你写出对读者（和未来的自己）语义清晰的 JavaScript 代码，也解释了为什么"少一个分号"有时会引发难以排查的运行时异常。

【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint