Markdown 里的反斜杠：为什么转义方括号不该报空链接

做 Markdown 发布前检查时，我遇到一个很容易漏掉的边界：文稿里写了 \[空]()，轻量检查器却把它当成了一个地址为空的链接。作者原本只是想展示链接语法，结果检查报告给出一条误报。

先看两种容易混淆的输入

\[空]()               转义了左方括号，属于普通文字
\\[空]()              两个反斜杠后，左方括号仍能开启链接

关键在于标记前连续反斜杠的个数：奇数个会转义紧随其后的标记；偶数个则把反斜杠两两配对，标记本身继续生效。只看正则是否匹配到 [...](...)，无法区分这两种情况。

一次小改动

我的检查器原来先用正则找同一行的简易链接和图片，再判断地址是否为空。现在增加一个 isEscaped(line, index)：从待判断字符的前一位向左数连续的反斜杠，按奇偶判断该字符是否被转义。

function isEscaped(line, index) {
  let backslashes = 0;
  for (let i = index - 1; i >= 0 && line[i] === '\\'; i--) backslashes++;
  return backslashes % 2 === 1;
}

匹配到链接后，先检查左方括号：若它被转义，就忽略这次匹配。对于以感叹号开头的图片写法，还要单独检查感叹号是否被转义；被转义的感叹号不应触发“图片缺少替代文字”的提示。这个顺序保留了真正空链接和真正图片的提示，也减少了代码示例中的误报。

用浏览器核验结果

我在 Edge 中实际输入两种方括号写法以及图片相关的两种写法：转义左方括号计为 0 个链接；两个反斜杠后计为 1 个空链接；转义感叹号计为 1 个普通链接且不报图片问题；未转义的空替代文字图片仍给出提示。修复后的单文件工具已更新到 GitCode 的 markdown-lint-board 仓库。

这是一个面向发布前检查的轻量规则，不是完整 Markdown 解析器。复杂嵌套、引用式链接和跨行语法仍需用更完整的解析器或人工校对。