HTML编辑器中“缩进字符宽度”本质是两件事：一是编辑时插入的缩进单位（空格或\t），二是渲染含\t的代码时浏览器如何显示——后者才真正用到tab-size，且仅在<pre>等white-space:pre容器、等宽字体、现代浏览器支持下对真实\t字符生效。
直接说结论：HTML 编辑器里所谓“缩进字符宽度”，本质是两件事：一是编辑时插入的缩进单位（空格 or \t），二是渲染含 \t 的代码时浏览器怎么显示它——后者才真正用到 tab-size，且只在特定条件下生效。
tab-size CSS 属性到底对谁起作用
tab-size 不控制你按 Tab 键插入什么，也不影响空格缩进；它只决定「已有 \t 字符」在 <pre>、<code> 或 white-space: pre 容器里渲染多宽。
- 必须配合等宽字体（如
font-family: 'SFMono-Regular', Consolas, monospace），否则数值无意义 - 只在 Chrome 21+、Firefox 73+、Safari 15.4+、Edge 79+ 原生支持；旧版 Safari 需
-webkit-tab-size，Firefox 4–72 只认-moz-tab-size - 给
<textarea>设tab-size: 4没用——它不解析\t渲染，按 Tab 键默认会移出焦点，得靠 JS 拦截并插入空格 - 对
<table><td>直接设tab-size无效，\t在white-space: normal下被当普通空白吞掉
在 contenteditable 编辑器中让 tab-size 生效的硬性条件
如果你用 div[contenteditable] 或 <pre><code> 实现轻量编辑器，想让 tab-size 控制视觉缩进，必须同时满足：
- 容器有
white-space: pre或pre-wrap（不能是normal） - 内容里真实存在
\t字符（不是空格拼出来的） - 字体是等宽字体，且未被父级 CSS 的
font-family覆盖 - 没有更高优先级的 CSS 把
white-space改回normal（比如父<div>设了white-space: pre-wrap，子<code>却设了white-space: pre，可能意外失效）
漏掉任一条件，tab-size: 2 就只是个摆设。
立即学习“前端免费学习笔记（深入）”；
为什么编辑器设置「缩进为 2 空格」时不该动 tab-size
现代编辑器（VS Code、WebStorm）和格式化工具（Prettier）默认把用户 Tab 键转成固定数量空格（如 "editor.insertSpaces": true, "editor.tabSize": 2）。此时所有缩进都是 ASCII （空格字符），tab-size 完全无关——它只管 \t，不管空格。
- 若你启用了空格缩进，CSS 里删掉
tab-size更干净，避免误导后续维护者 - 若团队混用空格和 Tab（比如 Prettier 默认保留原缩进），建议统一转为空格，否则复制到 GitHub 或 VS Code 时，对方编辑器按自身
tab-size渲染，视觉错位是必然的 - EditorConfig 中
indent_style = space和indent_size = 4是落地关键，比任何 CSS 都管用
真实项目中最容易被忽略的三个缩进断层
即使你写了 tab-size: 4 且浏览器支持，以下三点仍会让缩进在协作中“突然变歪”：
- 字体没锁死等宽：某个组件 CSS 加了
font-family: "Helvetica"，覆盖了全局等宽设置，tab-size: 4在非等宽字体下失去语义 - 复制粘贴时环境切换：你在编辑器里设
tab-size: 2，但把代码粘到 GitHub README，GitHub 渲染用的是自己的tab-size: 8，看起来缩进爆炸——这不是 bug，是预期行为 - 混合缩进未清理：某段 HTML 是手写 Tab，另一段是 Prettier 格式化后的空格，
tab-size只修正前者，后者完全不受控，混排后对齐漂移
真正可控的，永远是「输入时强制统一」，而不是「渲染时靠 CSS 补救」。
