Tab/Shift+Tab在VS Code中缩进Markdown列表层级而非单纯插入空格，需光标位于列表项内才触发智能缩进；自动编号依赖autoRenumber设置及上下文连续性；GitHub等平台因CommonMark规范限制可能导致嵌套失效。
Tab/Shift+Tab 在列表中到底缩进什么
VS Code 里按 Tab 并不是简单地插入 2 或 4 个空格——它操作的是 Markdown 列表的层级结构。对有序或无序列表项执行 Tab，插件会识别当前行是否为列表项，然后在行首插入恰当数量的空格（通常是 2 或 4，取决于你配置的 editor.tabSize），使该行成为上一级列表的子项。
常见错误现象：
- 在非列表行按
Tab，只触发普通缩进（插入空格），不改变语义 - 在列表项末尾按
Tab，可能被误判为代码块起始，导致渲染异常 - 嵌套过深时（比如 >4 层），部分预览器（如 GitHub）会忽略深层缩进，仅显示前 3 层
实操建议：
- 确保光标落在列表项的任意位置（包括行首、中间或末尾），再按
Tab才能触发智能缩进 - 用
Shift+Tab提升层级时，若当前已是顶层，则不会报错，但也不会生效——这是正常行为，不是 bug - 如果缩进后预览没变化，检查是否启用了
markdown.extension.orderedList.autoRenumber和markdown.extension.list.indentation相关设置
1. 输入后回车为何有时编号不递增
输入 1. 后按 Enter 能否自动续编，取决于两个关键开关：一是 markdown.extension.orderedList.autoRenumber 是否启用；二是当前行是否被正确识别为“有序列表上下文”。后者容易被干扰——比如前面有空行、注释、HTML 标签或非标准换行符（\r\n vs \n）。
典型场景：
- 在表格后面紧接输入
1.，常无法触发自动编号（表格打断了列表上下文） - 复制粘贴的列表含混合编号（
1.、3.、2.），插件默认不重排，需手动触发命令Markdown: Renumber ordered list - 使用中文标点（如
１.全角数字加点）不会被识别，必须用 ASCII1.
参数差异：
-
autoRenumber控制“新增行时是否自动编号”，但不影响已有断序； -
renumberOnEdit（部分版本支持）才真正实现边编辑边重算，但性能开销略高； - 关闭
autoRenumber后，Tab缩进仍有效，但编号不再自动生成。
为什么缩进后复制到 GitHub 就乱了
这不是 VS Code 的问题，而是 Markdown 渲染器对缩进的解释规则不统一。VS Code 预览和 Typora 会忠实保留行首空格并渲染为嵌套结构；GitHub Flavored Markdown（GFM）则严格遵循 CommonMark 规范：只有连续 4 个空格或 1 个 Tab 才视为代码块缩进，列表缩进必须用空格对齐且层级间差值固定（通常 2 或 4 空格），否则降级为普通段落。
输入文章 URL，返回干净 Markdown。支持17个平台（头条、微信公众号、知乎、36kr、虎嗅、华尔街见闻、澎湃、InfoQ 等）专项优化，双引擎提取、图片本地化、三层抓取策略。常与 browser‑web‑search skill配合：先用 bws 搜索获取 url 列表，再逐篇调用本 skill 提取正文。
可验证的兼容性影响：
- 用
Tab缩进的列表，在 GitHub 上可能显示为平级项（失去嵌套） - 手动敲空格缩进，若每层空格数不一致（如第一层 2 空格、第二层 3 空格），GFM 会直接忽略缩进
- Obsidian 等支持 CSS 的工具可通过
.markdown-preview .list { padding-left: 1.5em }强制视觉缩进，但这不改变源码语义
实操建议：
- 对外交付文档（尤其要发 GitHub），优先用空格而非 Tab 缩进列表，并确保每层缩进量一致（推荐 2 空格）
- 避免在列表中混用 Tab 和空格——VS Code 默认将 Tab 插入为空格（当
editor.insertSpaces为 true），但粘贴内容可能带原始 Tab 字符 - 用命令
Editor: Convert Indentation to Spaces统一全文缩进类型
列表重编号命令的实际触发边界
Markdown: Renumber ordered list 命令不是全局重排，它只作用于“当前光标所在连续有序列表块”——即从上一个空行或非列表行开始，到下一个空行或非列表行结束之间的所有 1.～999. 行。跨空行、跨代码块、跨 HTML 标签都会中断这个连续块。
容易踩的坑：
- 在列表中间插入一个引用块
> text，再执行重编号，只会处理引用块之前或之后的片段，不会跨过去 - 列表项内含多行内容（如换行后跟缩进段落），只要没空行隔开，仍属同一块，会被一起重编号
- 命令对任务列表（
- [ ]）无效，它只处理1.、a.、i.这类有序标记
性能提示：
- 对超长列表（>500 行），该命令响应稍慢，建议分段操作
- 若列表含大量内联代码（
`1.`），插件可能误识别为真实编号，导致意外重排——此时应先临时注释掉干扰行
真正决定缩进和编号是否“看起来对”的，从来不是你按了多少次 Tab，而是 VS Code 插件能否把你的意图准确翻译成符合 CommonMark 规范的纯文本结构。而不同平台渲染器对同一段文本的理解差异，才是排版失控的根源。
