开发工具代码质量Lint静态分析【免费下载链接】markdownlintA Node.js style checker and lint tool for Markdown/CommonMark files.项目地址https://gitcode.com/gh_mirrors/ma/markdownlint点击查看免费下载导读本文以 markdownlint 仓库中的场景测试文件 test/headings-without-content.md 为主线深入讲解只有井号、没有任何正文内容的 ATX 空标题在 CommonMark 与 markdownlint 中的行为差异Markdown 解析器允许空标题存在而 markdownlint 的MD019no-multiple-space-atx规则会精准检查井号与标题文本之间是否使用了超过一个空格。读完本文你将掌握空标题的合法语法边界、如何用内联配置隔离单条规则进行测试、MD019 的判定与自动修复原理以及如何阅读本仓库的快照测试snapshot输出。一、场景测试文件全景markdownlint的test/目录下存放了大量场景测试 Markdown 文件每个文件本身就是一份自带预期结果的迷你测试。test/headings-without-content.md是其中专门验证空标题场景的用例全文共 22 行# Headings Without Content !-- markdownlint-disable single-title heading-style -- !-- markdownlint-disable no-duplicate-heading no-trailing-spaces -- # # # # ## ## ## ## {MD019:10} {MD019:12} {MD019:18} {MD019:20}从文件结构可以拆出三个层次标题行第 1 行# Headings Without Content是文件自身的标题注意它本身也是一个合法的#一级标题禁用注释第 3、4 行通过markdownlint-disable内联指令临时关闭 4 条规则把测试范围收敛到MD019一条规则上被测内容第 620 行是 8 个没有任何标题文本的 ATX 空标题4 个#、4 个##最后一行是测试标记marker。需要特别指出的是空标题本身是完全合法的 Markdown。CommonMark 规范允许#或##之后不跟任何文本micromark 解析器会把它们正常识别为atxHeading类型的标题 token——它们可以正常参与标题层级、锚点生成等后续处理。正因为语法合法markdownlint才对空标题里的空格数量这一纯格式问题单独立项为MD019。二、内联禁用注释如何把测试聚焦到 MD019文件第 3、4 行使用了 markdownlint 的内联配置指令这两行注释是理解整个测试的关键!-- markdownlint-disable single-title heading-style -- !-- markdownlint-disable no-duplicate-heading no-trailing-spaces --markdownlint-disable表示从当前行开始到文件末尾或遇到markdownlint-enable之前关闭指定规则。这里一共关闭了 4 条规则关闭原因都可以在对应文档与源码中找到依据规则别名文档为什么要关闭MD025single-title/single-h1doc/md025.md文档中出现了 5 个空的一级标题#会触发同一文档存在多个顶层标题MD003heading-styledoc/md003.md混合出现#与##等不同级别、且与首标题风格比较会触发标题风格不一致MD024no-duplicate-headingdoc/md024.md8 个空标题的文本内容全部相同都是空字符串会触发标题内容重复MD009no-trailing-spacesdoc/md009.md第 8、10、12、16、18、20 行在井号后存在行尾空格会触发行尾多余空格从源码实现看MD025在 lib/md025.mjs 中通过filterByTypesCached([atxHeading, setextHeading])收集所有顶层标题并报出除第一个之外的重复标题MD024在 lib/md024.mjs 中会记录每个标题的文本这里全部是空文本第二次出现相同文本即报错。因此如果不禁用这 4 条规则测试输出会被这些噪音污染无法单独验证 MD019 对空格数量的判定——这正是该文件两行禁用注释的用意把一条场景测试裁剪到只覆盖一条规则使断言结果精确可控。三、MD019 规则井号后多重空格的判定3.1 规则定义MD019的完整规则名是no-multiple-space-atx官方文档 doc/md019.md 定义如下规则名MD019/no-multiple-space-atx标签atx、headings、spaces可修复部分违规可由工具自动修复触发条件ATX 风格标题中井号#与标题文本之间使用了超过一个空格。例如# Heading 1 ## Heading 2正确写法是井号后只保留一个空格# Heading 1 ## Heading 2规则设计原理在文档中写得很直白额外的空格没有任何用途也不会影响渲染结果属于纯粹的多余格式。3.2 空标题场景下的特殊表现回到空标题场景当#后面没有任何文本、只有若干空格时这些空格恰好构成了atxHeadingSequence井号 token之后唯一的子 token。于是MD019的判定逻辑就转化为——检查空标题里井号后到底跟了几个空格# → 井号后 0 个空格MD019 不触发 # → 井号后 1 个空格MD019 不触发但 MD009 行尾空格会管它 # → 井号后 2 个空格MD019 触发第 10 行 # → 井号后 3 个空格MD019 触发第 12 行 ## → 2 个井号后 0 个空格不触发 ## → 2 个井号后 2 个空格MD019 触发第 18 行 ## → 2 个井号后 3 个空格MD019 触发第 20 行这正是测试文件第 22 行标记所声明的预期{MD019:10} {MD019:12} {MD019:18} {MD019:20}即只有第 10、12、18、20 行会报MD019。注意第 8、16 行各带 1 个空格的行不报 MD019因为 1 个空格是合法分隔它们的存在是为了证明单空格边界不会误报。四、源码级实现token 层面的扫描MD019与MD021闭式 ATX 标题的井号内侧空格共用同一套核心逻辑实现在 lib/md019-md021.mjs 中。4.1 空标题如何变成 token 流仓库使用 micromark 作为 Markdown 解析器见 package.json 中的micromark依赖与 lib/micromark-parse.mjs。#空标题会被解析为结构如下的 token 树atxHeading ├── atxHeadingSequence (#文本 #) └── whitespace (空格序列文本 )当井号后没有任何内容时whitespace就是标题里唯一的正文占位MD019扫描的正是这个whitespacetoken 的文本长度。4.2 核心判定函数 validateHeadingSpaceslib/md019-md021.mjs 中的validateHeadingSpaces(onError, heading, delta)是判定的核心function validateHeadingSpaces(onError, heading, delta) { const { children, startLine, text } heading; let index (delta 0) ? 0 : (children.length - 1); while ( children[index] (children[index].type ! atxHeadingSequence) ) { index delta; } const headingSequence children[index]; const whitespace children[index delta]; if ( (headingSequence?.type atxHeadingSequence) (whitespace?.type whitespace) (whitespace.text.length 1) ) { const column whitespace.startColumn 1; const length whitespace.endColumn - column; addErrorContext( onError, startLine, text.trim(), delta 0, delta 0, [ column, length ], { editColumn: column, deleteCount: length } ); } }关键点逐条拆解定位井号 token沿delta1 从前向后、-1 从后向前在标题的children中找到atxHeadingSequence它紧邻的下一个子 token 就是whitespace判定条件whitespace.text.length 1即空格数大于 1 才报错——1 个空格是合法分隔0 个空格#后直接换行也合法误差范围column whitespace.startColumn 1从第二个空格开始计算length是剩余空格数量。例如#井号 2 空格报错范围为[3, 1]只标记第 2 个空格#3 空格报错范围为[3, 2]修复信息fixInfo中editColumn指向第一个多余空格所在列deleteCount是要删除的空格个数——修复策略是删除多余空格、保留井号后那 1 个合法空格。MD019 的规则函数lib/md019-md021.mjs先按filterByTypesCached([atxHeading])收集所有 ATX 标题再借助 helpers/micromark-helpers.cjs 中的getHeadingStyle过滤出纯atx风格排除atx_closed闭式标题最后对每个标题调用validateHeadingSpaces(onError, atxHeading, 1)从前向后扫描。五、测试驱动的验证闭环5.1 场景测试机制markdownlint的场景测试由 test/markdownlint-test-scenarios.mjs 驱动。该文件会扫描test/目录下所有.md文件对每个文件执行两条并行操作第 22-27 行读取 Markdown 原文调用lint({ files: [file] })执行真实 lint。随后第 40-64 行用正则/\{(MD\d)(?::([-]?)(\d))?\}/g解析原文中的{MD019:10}这类标记把期望在第几行报哪条规则解析成expected字典再与 lint 实际输出比较多报或漏报都会导致断言失败。文件最后一行{MD019:10} {MD019:12} {MD019:18} {MD019:20}因此扮演了测试预期清单的角色。5.2 快照修复后的输出测试还会调用applyFixes生成修复后的内容并写入快照结果保存在 test/markdownlint-test-scenarios.mjs.snapshot。针对本文件的快照包含 4 条MD019错误每条都携带精确的定位与修复信息行号errorContexterrorRangefixInfo10##[3, 1]editColumn: 3, deleteCount: 112##[3, 2]editColumn: 3, deleteCount: 218####[4, 1]editColumn: 4, deleteCount: 120####[4, 2]editColumn: 4, deleteCount: 2快照中的fixed字段展示了自动修复的最终结果所有空标题被统一规整为井号 1 个空格如#、##。这与上一节源码中的fixInfo完全对应——只删多余空格、保留合法单空格。由于第 4 行已禁用MD009行尾空格修复后残留的那个单空格不会被二次报错同时 test/markdownlint-test-scenarios.mjs 还会对修复结果再次 lint确保所有可修复错误都被彻底修复。5.3 对照实验headings_good.mdtest/目录下的 test/headings_good.md 是本场景的对照组# Heading 1 ## Heading 2 ## Heading 3它对应的快照test/markdownlint-test-scenarios.mjs.snapshot中errors为空数组fixed与原文完全一致。这个对照说明只要标题有内容且井号后只有 1 个空格就不会触发 MD019 或任何其它标题相关规则——从正反两面印证了 MD019 判定条件的唯一变量就是井号后的空格数量。六、实战在自己的文档中规避与利用空标题6.1 空标题的正确姿势根据MD019的语义写空标题时应遵守两条约束井号后最多 1 个空格#或#都不会触发 MD019不要使用 2 个及以上的空格#、##都会报MD019并会被自动修复工具折叠为单空格形式。如果空标题是刻意为之例如用于占位、作为模板骨架建议#即只保留一个空格既满足 MD019又让渲染结果保持为标题。同时需要注意空标题会继续触发 MD025、MD024、MD003、MD009 等其它规则这正是测试文件要用两行禁用注释隔离它们的原因所以实践中更稳妥的做法是为标题补齐实际文本或按需在文件头部使用markdownlint-disable明确声明意图。6.2 亲手复现与验证如果你希望在本仓库中复现上述全部行为可以# 运行包含本场景在内的全部场景测试 npm run test # 仅运行场景测试 node --test test/markdownlint-test-scenarios.mjs # 重新生成快照更新测试预期 npm run update-snapshots其中npm run test在 package.json 中定义运行环境要求 Node.js22见 package.json 的engines字段。修改test/headings-without-content.md后运行场景测试即可观察断言与快照如何随文件变化从而深入理解 markdownlint 的测试文件即文档设计哲学。结语test/headings-without-content.md虽然只有 22 行却完整覆盖了 markdownlint 规则开发与测试的一条典型链路合法的空标题语法 → 用内联禁用注释隔离目标规则 → micromark token 级扫描 → 精确到列的空格计数 → 可自动修复的 fixInfo → 快照回归验证。它同时告诉我们一个容易被忽略的事实Markdown 语法合法不等于 lint 通过MD019这类格式化规则正是负责在语法与规范之间补齐最后一道约束的。理解了这个测试用例也就理解了 markdownlint 全部 60 条规则背后解析器 规则 测试 快照的统一工作模式后续阅读 lib/md019-md021.mjs 或 doc/Rules.md 中的其它标题类规则MD001、MD003、MD024、MD025时即可举一反三。赞分享开发工具代码质量Lint静态分析【免费下载链接】markdownlintA Node.js style checker and lint tool for Markdown/CommonMark files.项目地址https://gitcode.com/gh_mirrors/ma/markdownlint点击查看免费下载相关推荐markdownlint MD025「单标题」规则深度解析从测试用例到源码实现markdownlint MD025「单标题」规则深度解析从测试用例到源码实现 本文以 markdownlint 仓库版本 0.41.0中的测试夹具 te开发工具代码质量Lint静态分析Parsedown 的 Setext 标题空格规则从测试用例到 blockSetextHeader 源码实现Parsedown 的 Setext 标题空格规则从测试用例到 blockSetextHeader 源码实现 导读 Setext 标题是 Markdown 中后端markdownlint ATX 标题空格规则MD018–MD021测试用例全解析从 {MD} 标记到自动修复markdownlint ATX 标题空格规则MD018–MD021测试用例全解析从 {MD } 标记到自动修复 导读 本文以 markdownlint开发工具代码质量Lint静态分析上一篇Midday数据库索引优化为嵌入相似度搜索专门设计的索引方案下一篇终结系统幽灵System Informer高效清除僵尸进程全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/16 1:45:18 · 阅读 1.2k markdownlint 空标题（无内容标题）与 MD019 规则：从测试用例到源码实现
开发工具代码质量Lint静态分析【免费下载链接】markdownlintA Node.js style checker and lint tool for Markdown/CommonMark files.项目地址https://gitcode.com/gh_mirrors/ma/markdownlint点击查看免费下载导读本文以 markdownlint 仓库中的场景测试文件 test/headings-without-content.md 为主线深入讲解只有井号、没有任何正文内容的 ATX 空标题在 CommonMark 与 markdownlint 中的行为差异Markdown 解析器允许空标题存在而 markdownlint 的MD019no-multiple-space-atx规则会精准检查井号与标题文本之间是否使用了超过一个空格。读完本文你将掌握空标题的合法语法边界、如何用内联配置隔离单条规则进行测试、MD019 的判定与自动修复原理以及如何阅读本仓库的快照测试snapshot输出。一、场景测试文件全景markdownlint的test/目录下存放了大量场景测试 Markdown 文件每个文件本身就是一份自带预期结果的迷你测试。test/headings-without-content.md是其中专门验证空标题场景的用例全文共 22 行# Headings Without Content !-- markdownlint-disable single-title heading-style -- !-- markdownlint-disable no-duplicate-heading no-trailing-spaces -- # # # # ## ## ## ## {MD019:10} {MD019:12} {MD019:18} {MD019:20}从文件结构可以拆出三个层次标题行第 1 行# Headings Without Content是文件自身的标题注意它本身也是一个合法的#一级标题禁用注释第 3、4 行通过markdownlint-disable内联指令临时关闭 4 条规则把测试范围收敛到MD019一条规则上被测内容第 620 行是 8 个没有任何标题文本的 ATX 空标题4 个#、4 个##最后一行是测试标记marker。需要特别指出的是空标题本身是完全合法的 Markdown。CommonMark 规范允许#或##之后不跟任何文本micromark 解析器会把它们正常识别为atxHeading类型的标题 token——它们可以正常参与标题层级、锚点生成等后续处理。正因为语法合法markdownlint才对空标题里的空格数量这一纯格式问题单独立项为MD019。二、内联禁用注释如何把测试聚焦到 MD019文件第 3、4 行使用了 markdownlint 的内联配置指令这两行注释是理解整个测试的关键!-- markdownlint-disable single-title heading-style -- !-- markdownlint-disable no-duplicate-heading no-trailing-spaces --markdownlint-disable表示从当前行开始到文件末尾或遇到markdownlint-enable之前关闭指定规则。这里一共关闭了 4 条规则关闭原因都可以在对应文档与源码中找到依据规则别名文档为什么要关闭MD025single-title/single-h1doc/md025.md文档中出现了 5 个空的一级标题#会触发同一文档存在多个顶层标题MD003heading-styledoc/md003.md混合出现#与##等不同级别、且与首标题风格比较会触发标题风格不一致MD024no-duplicate-headingdoc/md024.md8 个空标题的文本内容全部相同都是空字符串会触发标题内容重复MD009no-trailing-spacesdoc/md009.md第 8、10、12、16、18、20 行在井号后存在行尾空格会触发行尾多余空格从源码实现看MD025在 lib/md025.mjs 中通过filterByTypesCached([atxHeading, setextHeading])收集所有顶层标题并报出除第一个之外的重复标题MD024在 lib/md024.mjs 中会记录每个标题的文本这里全部是空文本第二次出现相同文本即报错。因此如果不禁用这 4 条规则测试输出会被这些噪音污染无法单独验证 MD019 对空格数量的判定——这正是该文件两行禁用注释的用意把一条场景测试裁剪到只覆盖一条规则使断言结果精确可控。三、MD019 规则井号后多重空格的判定3.1 规则定义MD019的完整规则名是no-multiple-space-atx官方文档 doc/md019.md 定义如下规则名MD019/no-multiple-space-atx标签atx、headings、spaces可修复部分违规可由工具自动修复触发条件ATX 风格标题中井号#与标题文本之间使用了超过一个空格。例如# Heading 1 ## Heading 2正确写法是井号后只保留一个空格# Heading 1 ## Heading 2规则设计原理在文档中写得很直白额外的空格没有任何用途也不会影响渲染结果属于纯粹的多余格式。3.2 空标题场景下的特殊表现回到空标题场景当#后面没有任何文本、只有若干空格时这些空格恰好构成了atxHeadingSequence井号 token之后唯一的子 token。于是MD019的判定逻辑就转化为——检查空标题里井号后到底跟了几个空格# → 井号后 0 个空格MD019 不触发 # → 井号后 1 个空格MD019 不触发但 MD009 行尾空格会管它 # → 井号后 2 个空格MD019 触发第 10 行 # → 井号后 3 个空格MD019 触发第 12 行 ## → 2 个井号后 0 个空格不触发 ## → 2 个井号后 2 个空格MD019 触发第 18 行 ## → 2 个井号后 3 个空格MD019 触发第 20 行这正是测试文件第 22 行标记所声明的预期{MD019:10} {MD019:12} {MD019:18} {MD019:20}即只有第 10、12、18、20 行会报MD019。注意第 8、16 行各带 1 个空格的行不报 MD019因为 1 个空格是合法分隔它们的存在是为了证明单空格边界不会误报。四、源码级实现token 层面的扫描MD019与MD021闭式 ATX 标题的井号内侧空格共用同一套核心逻辑实现在 lib/md019-md021.mjs 中。4.1 空标题如何变成 token 流仓库使用 micromark 作为 Markdown 解析器见 package.json 中的micromark依赖与 lib/micromark-parse.mjs。#空标题会被解析为结构如下的 token 树atxHeading ├── atxHeadingSequence (#文本 #) └── whitespace (空格序列文本 )当井号后没有任何内容时whitespace就是标题里唯一的正文占位MD019扫描的正是这个whitespacetoken 的文本长度。4.2 核心判定函数 validateHeadingSpaceslib/md019-md021.mjs 中的validateHeadingSpaces(onError, heading, delta)是判定的核心function validateHeadingSpaces(onError, heading, delta) { const { children, startLine, text } heading; let index (delta 0) ? 0 : (children.length - 1); while ( children[index] (children[index].type ! atxHeadingSequence) ) { index delta; } const headingSequence children[index]; const whitespace children[index delta]; if ( (headingSequence?.type atxHeadingSequence) (whitespace?.type whitespace) (whitespace.text.length 1) ) { const column whitespace.startColumn 1; const length whitespace.endColumn - column; addErrorContext( onError, startLine, text.trim(), delta 0, delta 0, [ column, length ], { editColumn: column, deleteCount: length } ); } }关键点逐条拆解定位井号 token沿delta1 从前向后、-1 从后向前在标题的children中找到atxHeadingSequence它紧邻的下一个子 token 就是whitespace判定条件whitespace.text.length 1即空格数大于 1 才报错——1 个空格是合法分隔0 个空格#后直接换行也合法误差范围column whitespace.startColumn 1从第二个空格开始计算length是剩余空格数量。例如#井号 2 空格报错范围为[3, 1]只标记第 2 个空格#3 空格报错范围为[3, 2]修复信息fixInfo中editColumn指向第一个多余空格所在列deleteCount是要删除的空格个数——修复策略是删除多余空格、保留井号后那 1 个合法空格。MD019 的规则函数lib/md019-md021.mjs先按filterByTypesCached([atxHeading])收集所有 ATX 标题再借助 helpers/micromark-helpers.cjs 中的getHeadingStyle过滤出纯atx风格排除atx_closed闭式标题最后对每个标题调用validateHeadingSpaces(onError, atxHeading, 1)从前向后扫描。五、测试驱动的验证闭环5.1 场景测试机制markdownlint的场景测试由 test/markdownlint-test-scenarios.mjs 驱动。该文件会扫描test/目录下所有.md文件对每个文件执行两条并行操作第 22-27 行读取 Markdown 原文调用lint({ files: [file] })执行真实 lint。随后第 40-64 行用正则/\{(MD\d)(?::([-]?)(\d))?\}/g解析原文中的{MD019:10}这类标记把期望在第几行报哪条规则解析成expected字典再与 lint 实际输出比较多报或漏报都会导致断言失败。文件最后一行{MD019:10} {MD019:12} {MD019:18} {MD019:20}因此扮演了测试预期清单的角色。5.2 快照修复后的输出测试还会调用applyFixes生成修复后的内容并写入快照结果保存在 test/markdownlint-test-scenarios.mjs.snapshot。针对本文件的快照包含 4 条MD019错误每条都携带精确的定位与修复信息行号errorContexterrorRangefixInfo10##[3, 1]editColumn: 3, deleteCount: 112##[3, 2]editColumn: 3, deleteCount: 218####[4, 1]editColumn: 4, deleteCount: 120####[4, 2]editColumn: 4, deleteCount: 2快照中的fixed字段展示了自动修复的最终结果所有空标题被统一规整为井号 1 个空格如#、##。这与上一节源码中的fixInfo完全对应——只删多余空格、保留合法单空格。由于第 4 行已禁用MD009行尾空格修复后残留的那个单空格不会被二次报错同时 test/markdownlint-test-scenarios.mjs 还会对修复结果再次 lint确保所有可修复错误都被彻底修复。5.3 对照实验headings_good.mdtest/目录下的 test/headings_good.md 是本场景的对照组# Heading 1 ## Heading 2 ## Heading 3它对应的快照test/markdownlint-test-scenarios.mjs.snapshot中errors为空数组fixed与原文完全一致。这个对照说明只要标题有内容且井号后只有 1 个空格就不会触发 MD019 或任何其它标题相关规则——从正反两面印证了 MD019 判定条件的唯一变量就是井号后的空格数量。六、实战在自己的文档中规避与利用空标题6.1 空标题的正确姿势根据MD019的语义写空标题时应遵守两条约束井号后最多 1 个空格#或#都不会触发 MD019不要使用 2 个及以上的空格#、##都会报MD019并会被自动修复工具折叠为单空格形式。如果空标题是刻意为之例如用于占位、作为模板骨架建议#即只保留一个空格既满足 MD019又让渲染结果保持为标题。同时需要注意空标题会继续触发 MD025、MD024、MD003、MD009 等其它规则这正是测试文件要用两行禁用注释隔离它们的原因所以实践中更稳妥的做法是为标题补齐实际文本或按需在文件头部使用markdownlint-disable明确声明意图。6.2 亲手复现与验证如果你希望在本仓库中复现上述全部行为可以# 运行包含本场景在内的全部场景测试 npm run test # 仅运行场景测试 node --test test/markdownlint-test-scenarios.mjs # 重新生成快照更新测试预期 npm run update-snapshots其中npm run test在 package.json 中定义运行环境要求 Node.js22见 package.json 的engines字段。修改test/headings-without-content.md后运行场景测试即可观察断言与快照如何随文件变化从而深入理解 markdownlint 的测试文件即文档设计哲学。结语test/headings-without-content.md虽然只有 22 行却完整覆盖了 markdownlint 规则开发与测试的一条典型链路合法的空标题语法 → 用内联禁用注释隔离目标规则 → micromark token 级扫描 → 精确到列的空格计数 → 可自动修复的 fixInfo → 快照回归验证。它同时告诉我们一个容易被忽略的事实Markdown 语法合法不等于 lint 通过MD019这类格式化规则正是负责在语法与规范之间补齐最后一道约束的。理解了这个测试用例也就理解了 markdownlint 全部 60 条规则背后解析器 规则 测试 快照的统一工作模式后续阅读 lib/md019-md021.mjs 或 doc/Rules.md 中的其它标题类规则MD001、MD003、MD024、MD025时即可举一反三。赞分享开发工具代码质量Lint静态分析【免费下载链接】markdownlintA Node.js style checker and lint tool for Markdown/CommonMark files.项目地址https://gitcode.com/gh_mirrors/ma/markdownlint点击查看免费下载相关推荐markdownlint MD025「单标题」规则深度解析从测试用例到源码实现markdownlint MD025「单标题」规则深度解析从测试用例到源码实现 本文以 markdownlint 仓库版本 0.41.0中的测试夹具 te开发工具代码质量Lint静态分析Parsedown 的 Setext 标题空格规则从测试用例到 blockSetextHeader 源码实现Parsedown 的 Setext 标题空格规则从测试用例到 blockSetextHeader 源码实现 导读 Setext 标题是 Markdown 中后端markdownlint ATX 标题空格规则MD018–MD021测试用例全解析从 {MD} 标记到自动修复markdownlint ATX 标题空格规则MD018–MD021测试用例全解析从 {MD } 标记到自动修复 导读 本文以 markdownlint开发工具代码质量Lint静态分析上一篇Midday数据库索引优化为嵌入相似度搜索专门设计的索引方案下一篇终结系统幽灵System Informer高效清除僵尸进程全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考