本文约 4,048 字，预计阅读 11 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：装个高亮插件，前端多出六个请求
技术博客的核心体验之一就是代码块可读：语法着色、等宽字体、行号、一键复制。WordPress 原生只有一个「代码」区块，输出 <pre class="wp-block-code"><code>，没有任何着色——灰色等宽字体一整块，读起来很累。
于是装插件。装完打开 Chrome 网络面板一看：多了一个主题 CSS、一个核心 JS、四五个语言包 JS，全站每个页面都加载。博客首页十篇文章里可能只有一篇有代码，却要为全部页面付出这些请求。
这就是选型的第一个分水岭：插件是否支持按需加载。第二个分水岭是能否与古腾堡区块编辑器共存（有些老插件只有短代码，写起来别扭）。第三个是语言包的体积（PHP、JS、Nginx、SQL、Bash 各自一个文件，全量加载很浪费）。
原理分析：四类方案的工作方式
| 方案 | 形态 | 着色库 | 特点 |
|---|---|---|---|
| SyntaxHighlighter Evolved | 短代码 [code lang="php"] |
SyntaxHighlighter（Alex Gorbatchev） | 老牌、稳定，短代码写法，无区块 |
| Enlighter | 短代码 [code lang="php"] + 古腾堡区块 |
EnlighterJS | 配置细（主题、行号、缩进），自带 Gutenberg 块 |
| Prismatic 插件 | 短代码 + 设置切换 | Prism.js 或 highlight.js 二选一 | 轻量，可切换底层库 |
| Code Syntax Block（区块插件） | 古腾堡 core/code 的增强版 |
highlight.js 或 Prism | 原生区块体验，编译期着色，前台零额外脚本 |
| 自托管 Prism.js | 主题里手工引入 | Prism.js | 完全可控，按需加载语言包 |
关键区别在于着色发生在什么时候：
- 运行时着色：前台加载 JS，浏览器遍历
pre code做着色（Prism、Enlighter、SyntaxHighlighter 都是这类）。代价是额外请求与一次 DOM 计算。 - 编译期着色：保存文章时就把 HTML 生成好，前台只是渲染带 class 的 span（Code Syntax Block 这类区块插件的做法）。前台几乎零开销，代价是已发布文章的样式改起来要重新保存。
对中文技术博客来说，还有一个很实际的问题：代码块里出现中文注释时，着色是否会破坏中文。多数库按 token 着色，中文注释一般安全，但如果主题给 pre 设置了不合适的 font-family，中文会掉到默认字体，行高错乱。
保姆级实操
第一步：确定你需要哪些语言
先列出自己实际会贴的语言。多数 WordPress 博客只需要：PHP、Bash、Nginx、SQL、JS、CSS、HTML、JSON、YAML。把这九种之外的语言包全部排除，能省掉一半以上的请求。
第二步：小站点优先用古腾堡区块方案
如果文章全部用区块编辑器写，优先试 Code Syntax Block 这类”增强原生代码块”的插件：它给 core/code 区块加上语言选择、行号、着色开关，输出时直接生成带 class 的 HTML。优点是不引入前台 JS，也不改变写作习惯。
第三步：需要短代码时用 Enlighter 或 SyntaxHighlighter Evolved
两者都支持在经典编辑器或短代码里写：
[code lang="php"]
echo 'Hello';
[/code]
Enlighter 的优势是有古腾堡区块、可配置主题与行号、支持分组加载语言（只加载勾选的语言）；SyntaxHighlighter Evolved 的优势是老牌稳定、短代码简短（[php] 也能用），适合还在用经典编辑器或大量存量短代码的站点。
第四步：追求极致可控就自托管 Prism.js
从 Prism 官网按需勾选语言与插件，下载合并后的 CSS/JS，放进主题自己加载，完全不依赖插件：
add_action( 'wp_enqueue_scripts', function () {
// 只在文章页加载，首页/归档页不加载
if ( ! is_singular( 'post' ) ) {
return;
}
// 手动模式：加载核心 + 需要的语言，不自动高亮
wp_enqueue_style(
'prism',
get_theme_file_uri( '/assets/prism.min.css' ),
array(),
'1.29.0'
);
wp_enqueue_script(
'prism-core',
get_theme_file_uri( '/assets/prism-core.min.js' ),
array(),
'1.29.0',
true
);
// 按需：只加载这几个语言包
foreach ( array( 'php', 'bash', 'sql', 'javascript', 'css', 'json' ) as $lang ) {
wp_enqueue_script(
'prism-' . $lang,
get_theme_file_uri( '/assets/prism-' . $lang . '.min.js' ),
array( 'prism-core' ),
'1.29.0',
true
);
}
} );
在页面上告诉 Prism 用手动模式并指定触发时机：
<!-- data-manual 告诉 Prism 不要自动执行 -->
<script src="/wp-content/themes/mytheme/assets/prism-core.min.js" data-manual></script>
<script>
document.addEventListener( 'DOMContentLoaded', function () {
if ( window.Prism ) {
// 只高亮带 .language-xxx 的块，避免误伤主题输出
Prism.highlightAll();
}
} );
</script>
第五步：按需加载的更细粒度控制
只想给”确实有代码块的文章”加载脚本，可以在保存时标记一篇文章是否包含代码（检测 has_block( 'core/code' ) 之类），再在渲染时判断是否入队。这样连单篇文章都能省掉。
第六步：统一代码块的视觉规范
不管用哪个方案，CSS 层面都要做三件事：等宽字体栈要包含中文、长行允许横向滚动、代码块与正文有明显区分（背景色 + 边框）。
常见踩坑
- 全站加载全部语言包。 默认配置往往把二十几种语言全带上，首屏多出几百 KB。只保留实际用到的。
- 主题自带的
pre样式把高亮结果覆盖了。 主题给code设了背景色或color，导致高亮颜色看不清。用更具体的选择器（.wp-block-code code、.language-php）覆盖。 - 编辑器里看着有色，前台没有。 多数高亮插件只在前台加载资源，古腾堡编辑器里的着色需要插件专门支持（这也是 Code Syntax Block 这类区块插件的优势）。
- 切换插件后存量短代码失效。 从 SyntaxHighlighter 换成 Enlighter，
[code lang="php"]可能变成未注册短代码，直接以文本形式显示出来。迁移前先在测试站点验证，必要时保留旧插件或写兼容短代码。 - 代码里的中文注释被主题转成全角引号。 这是
wptexturize的锅，处理办法参见 代码插入与展示最佳实践。 - 复制代码时把行号一起复制了。 用 CSS 计数器（
counter-increment）实现行号，而不是把行号写进<td>，复制时才不会带上行号。 - 案例： 某站装了一款高亮插件，配置页里默认勾选了全部语言。上线后 Lighthouse 性能分从 92 掉到 61，主要扣分项是”减少未使用的 JavaScript”——首页加载了 14 个语言包共 210KB。改成只勾选 PHP/Bash/SQL/JS 四种，并把脚本限制在
is_singular()页面加载后，首页请求数减少 12 个，性能分回到 89。教训：高亮是”锦上添花”型功能，绝不能让它拖累所有页面，按需加载是底线。
总结
选型建议：区块编辑器写文、想要零前台开销 → 区块类插件（Code Syntax Block）；大量存量短代码 → SyntaxHighlighter Evolved 或 Enlighter；追求极致可控 → 自托管 Prism.js 并按 is_singular() 加载。
三条硬约束：只加载实际用到的语言包；只在有代码的页面加载；主题样式与插件样式要显式对齐，避免互相覆盖。做完这些，代码块的视觉规范（字体、滚动、行号、复制按钮）再按 代码插入与展示最佳实践 统一收口。如果你还在搭建站点的内容结构，表格类内容可以顺带参考 TablePress 表格插件教程。
