pre标签本身能保留空格和换行，但前提是dom文本节点中真实存在这些字符；问题常源于模板转义、js注入、html压缩、css覆盖white-space或错误使用innerhtml导致换行符丢失。

pre 标签本身就能保留空格和换行，但前提是这些字符真实存在于 DOM 文本节点中——它不修复丢失的换行，也不兜底处理模板转义或 JS 注入导致的空白丢失。

为什么 pre 里空格和换行没显示出来

根本不是标签失效，而是内容在到达 pre 前就被“吃掉”了：

• 服务端模板（如 EJS、Django）默认对插值内容做 HTML 转义，<pre class="brush:php;toolbar:false;">hello world</pre> 中的 会变成字面量 字符串，浏览器收不到真实换行符
• 用 innerHTML 动态写入时，若字符串含 或 <code>> 未转义，会被解析为标签，破坏原始结构
• HTML 文件被压缩（minified），源码中本就没有换行和缩进，pre 无从保留
• CSS 覆盖了 white-space，比如某 reset.css 设了 white-space: normal，直接覆盖掉 pre 默认的 pre 值
• 动态注入内容时 pre 不保留换行，问题不在 pre，而在插入路径选错了

用 textContent 注入才能保证换行符原样进入 DOM

textContent 是唯一能 100% 保证换行符原样进入 DOM 的方式。它绕过 HTML 解析，把字符串当纯文本处理，连 & 都不会被二次解析。

• 正确：el.textContent = "line1 line2 indented";
• 错误：el.innerHTML = "<pre class="brush:php;toolbar:false;">line1 line2</pre>"; —— 在 JS 字符串中是换行，但拼进 HTML 后可能被解析器忽略或截断
• Vue 中避免用 {{ }} 插值（默认转义），改用 v-text 或 v-html（后者需确保内容可信）
• React 中用 {sourceString} 是安全的（JSX 默认 textContent 行为），但若来源是用户输入，仍需提前 HTML 转义（如用 DOMPurify.sanitize()）

pre 显示错位？大概率是字体或 CSS 干扰

空格和换行确实保留了，但如果用的是非等宽字体， 和空格宽度不一致，缩进就塌了。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• 必须显式设置等宽字体：pre { font-family: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace; }
• 避免用 font-family: system-ui 这类兜底值，它在不同系统可能 fallback 到非等宽字体
• 检查 computed styles 中 white-space 是否仍为 pre 或 pre-wrap；某些全局 CSS 会重置它
• 别在 pre 内部嵌套 <p></p> 或 <div>，它们会脱离预格式化上下文，导致换行逻辑断裂<h3>服务端返回的字符串在 <code>pre 中换行消失

  典型场景：API 返回 JSON 字段含换行符，前端直接赋值却只显示一行。问题常出在模板引擎或 JSX 插值环节。

  • 后端返回前确保换行符是真实字节，不是字符串 "line1 line2"（即 JSON 中应为 "line1 line2"，而非 "line1\nline2"）
  • 前端接收后不要二次 JSON.stringify() 或拼接，直接用 textContent 设置：preEl.textContent = apiResponse.text
  • EJS 用 （带短横）代替 ，跳过转义
  • Nunjucks / Django 用 {{ rawContent|safe }}，但必须确保内容可信，否则有 XSS 风险

  真正容易被忽略的点是：pre 的“保留”只发生在 HTML 解析阶段；一旦内容通过 JS 改写、框架重渲染、或被 CSS white-space 覆盖，它的保护就失效了。别假设它是个万能格式罩子——它只在原始 HTML 文本进入解析器那一刻起效。