背景
在 Sublime Text 查看 Markdown 文档时，个别“空行”被标成红色，初看像“尾随空白”问题，但清理空格无效。本文复盘一次完整排查，厘清根因并给出治理方案与对外口径。
现象
- 仅少数空白行被高亮为红色
- 删除空格/Tab 无效
- 保存后仍提示问题
根因分析
- 非尾随空白：二进制检查显示问题行无空格/Tab
- 非换行符差异：EOL 为统一 LF
- 真正原因：Markdown Lint 规则 MD012（consecutive blank lines，连续空行）被插件/主题（如 MarkdownLint/LSP/Git 集成）标记为错误
- 所以“红色”并非内容脏，而是规范违规提示
如何快速自证（定位步骤）
- 显示不可见字符：开启 draw_white_space 或 Show Invisibles，确认无尾随空白
- 比较换行：统一 LF，排除 CRLF/混用导致的误报
- 插件归因：逐步禁用 TrailingSpaces/GitGutter/MarkdownLint，观察仅 Markdown 规则关闭时红色消失
- 内容验证：减少连续空行后，提示即消失
二进制级验证（原理要点）
- 去除行末 \r/\n 后检查尾随空格/Tab → 问题行为空
- 检查 EOL：问题行使用 LF，且文件无混行
- 结论：并非字节差异，而是语义规则（MD012）触发
解决方案
- 内容整改（推荐）
- 避免相邻出现两行及以上空行，保留一行分段空行
- 规则配置（按需）
- 在项目里放宽或关闭 MD012
- 允许少量连续空行用于视觉分隔时，可设最大值
- 局部豁免（最小化影响）
- 仅对特定文档或目录禁用
- 编辑器一致性
- 统一 EOL=LF、保存时 Trim Trailing Whitespace、防止误判噪音
配置示例
- .markdownlint.json
{
"MD012": false
}
或
{
"MD012": { "maximum": 1 }
}
- Sublime 用户设置
{
"trim_trailing_white_space_on_save": true,
"ensure_newline_at_eof_on_save": true,
"default_line_ending": "unix"
}
团队沟通口径（对外说明）
- 问题并非“尾随空白”，而是 Markdown 规范 MD012：连续空行
- 编辑器/插件按规范将其标为错误以促进可读性与一致性
- 已通过清理多余空行（或调整规则）解决，并统一编辑器与 CI 配置
最佳实践
- 写作时仅保留单个空行分段
- 在仓库根添加 .markdownlint.json 固化规则
- 编辑器开启保存时清理与统一换行
- PR/CI 接入 markdownlint，避免个人环境差异
FAQ
- 为什么有的空行不红？只有“连续空行”才触发 MD012
- VS Code/其他 IDE 也会红吗？若启用 MarkdownLint 等，同样会提示
- 能否保留视觉空白？可以，通过放宽 MD012 的 maximum 或局部禁用
结语
这类“看似空行”的红色警示，往往是规范在发挥作用。与其对抗工具，不如将规则纳入工程体系，用统一的内容规范与工具链把“个人习惯问题”变成“团队一致性”。
