在维护中英文 WordPress 博客的过程中，我一直希望文章列表中的摘要能够尽量完整显示。
原因很简单：对于首页、分类页、标签页和搜索结果页来说，摘要并不只是装饰。读者通常会先通过标题和摘要判断文章是否与自己有关，再决定是否进入详情页。如果摘要只显示很短的一截，很多文章还没有把背景和核心内容交代清楚就已经被截断，实际阅读体验并不好。
这个问题最开始看起来很简单，但实际处理过程却比我预想中曲折得多。
最终经过一段时间的实际运行和再次验证，我确认了一件事：
使用 WPCode 修改 Gutenberg
Post Excerpt区块的excerptLength，确实能够让中英文文章列表中的摘要基本完整显示。
而且现在已经在中文首页、中文分类页以及英文搜索结果页得到实际验证。
一、最初的问题：中文摘要尤其容易显得太短
WordPress Gutenberg 的 Post Excerpt 区块提供了“最大字数”设置。
我最开始使用的是：
55
但实际前台效果中，中文摘要明显太短。
后来我把主题中的摘要长度提高到了：
100
这样已经比原来好很多。
不过，我真正想实现的并不是“比以前多显示一点”，而是：
如果文章已经有专门填写好的摘要，就尽量把这个摘要完整展示出来。
尤其现在不少文章的摘要已经经过专门生成和整理，本身就是一段完整的文章简介。如果列表页只显示前 100 个字符，仍然会损失一部分信息。
从截图中可以看到，摘要已经比最初的 55 长了不少，但仍然会在中间被截断，并显示省略号。
这说明：
100
更适合作为一个保底值，而不是最终目标。
二、通过 WPCode 将 Post Excerpt 长度提高到 500
我的最终方案并不复杂。
继续使用 WPCode，新建一个 PHP Snippet：
/**
* SWQ：列表页 Post Excerpt 尽量完整显示文章摘要。
*/
add_filter(
'render_block_data',
function ( $parsed_block ) {
if ( 'core/post-excerpt' === ( $parsed_block['blockName'] ?? '' ) ) {
$parsed_block['attrs']['excerptLength'] = 500;
}
return $parsed_block;
},
20
);
核心逻辑只有一件事：
$parsed_block['attrs']['excerptLength'] = 500;
也就是在 Gutenberg 的 core/post-excerpt 区块真正渲染之前，把摘要长度上限提高到 500。
对于我现在正常生成的中英文文章摘要来说，500 已经远远高于绝大多数摘要的实际长度，因此实际效果基本等同于：
完整显示已有摘要。
这里并没有修改数据库中的摘要，也没有重新生成摘要，只是在前台渲染时放宽显示长度。
三、将页面判断交给 WPCode，而不是继续堆 PHP 判断
最初也可以在 PHP 代码中通过：
is_front_page()
is_home()
is_archive()
is_search()
判断当前页面。
不过既然 WPCode 本身已经提供了 Location 和 Smart Conditional Logic，我更希望：
WPCode 决定“在哪里运行”，PHP 代码只负责“运行以后做什么”。
这样代码本身会简单很多。
最终设置为：
Insert Method：Auto Insert
Location：Frontend Conditional Logic
这样页面范围直接交给 WPCode 控制。
PHP 代码里面也不需要再加入首页、归档页、搜索页等页面类型判断。
四、Smart Conditional Logic 只保留三类列表页面
接下来开启：
Enable Logic
条件选择：
Show
然后建立三个独立的条件组：
Homepage
OR
Archive
OR
Search Page
三个条件组之间使用的是 OR。
也就是说，只要当前页面属于其中任意一种，Snippet 就会运行。
Homepage
负责首页文章列表。
Archive
负责各种归档列表，例如：
分类页
标签页
日期归档
其他分类法归档
Search Page
负责站内搜索结果。
我没有加入 Author Page。
因为我的网站已经关闭作者归档的 SEO 展示，因此没有必要再专门维护这一类列表页面。
最终职责就非常清楚：
WPCode
│
├── Homepage
├── Archive
└── Search Page
↓
PHP Snippet
↓
core/post-excerpt
↓
excerptLength = 500
五、为什么我一度以为这段代码没有效果？
这里其实是整个过程最有意思的地方。
早期测试时，我曾经反复切换：
excerptLength = 500
甚至故意测试：
excerptLength = 5
但前台页面一度看起来完全没有变化。
于是排查范围逐渐扩大到了：
W3 Total Cache
对象缓存
页面缓存
CDN
WPCode 执行状态
Gutenberg 区块渲染
PHP 代码缓存
最后甚至专门用临时 MU Plugin 验证 Gutenberg 的区块渲染链。
当时能够确认：
attrs=5
early=6
late=6
final=6
也就是说，excerptLength = 5 本身实际上是有效的。
5 个字符再加上省略号，最终长度正好大约为 6。
这说明：
render_block_data → core/post-excerpt → excerptLength
这一条技术路线本身没有问题。
真正让判断变复杂的，是生产环境中的多层缓存以及代码更新生效时机。
六、几天后意外发现：摘要其实一直是完整显示的
事情真正出现转折，是几天以后。
我发现中英文网站文章列表里的摘要，实际上已经基本完整显示。
我原本一直以为：
这是因为主题中的摘要长度已经从 55 提高到了 100。
直到后来偶然发现：
SWQ 列表页完整显示文章摘要
这个 WPCode Snippet 居然一直处于启用状态。
于是我主动把它停用了。
结果过了一段时间再次观察前台：
摘要重新变成了大约 100 个字符，并再次出现明显的截断。
这就形成了一个非常直接的对照实验：
WPCode 启用
excerptLength = 500
↓
摘要基本完整显示
而：
WPCode 停用
↓
退回主题设置
excerptLength = 100
↓
摘要再次被截断
到了这里，实际上已经可以确认：
真正让文章列表完整显示摘要的，就是这段 WPCode 代码。
而主题中的 100，只是代码片段停用后的后备值。
七、重新整理 WPCode 配置后继续观察
确认代码确实有效以后，我重新启用了这个 Snippet，同时把配置进一步整理成：
Location：
Frontend Conditional Logic
Enable Logic：
开启
条件：
Homepage
OR Archive
OR Search Page
代码仍然保持极简：
/**
* SWQ：列表页 Post Excerpt 尽量完整显示文章摘要。
*/
add_filter(
'render_block_data',
function ( $parsed_block ) {
if ( 'core/post-excerpt' === ( $parsed_block['blockName'] ?? '' ) ) {
$parsed_block['attrs']['excerptLength'] = 500;
}
return $parsed_block;
},
20
);
然后没有再立即频繁清缓存和反复修改，而是让它在真实生产环境中自然运行一段时间。
八、最终验证一：中文首页摘要完整显示
再次观察中文首页，可以看到列表中的摘要已经完整展开。
例如首页第一篇文章的摘要已经能够完整交代：
- ThinkPad T570 的 Type-C 转 VGA 问题；
- 为什么最终放弃继续修复原链路；
- 新显示器如何通过 HDMI 直接连接；
- Ubuntu 双屏恢复后的实际结果；
- 对 Thunderbolt 和 DisplayPort Alt Mode 的最终判断。
如果还是原来的 55 或 100 个字符，这些信息很难在文章列表里完整表达。
现在读者不进入详情页，也已经可以比较清楚地判断：
这篇文章到底解决了什么问题。
这正是我最初希望达到的效果。
九、最终验证二：中文分类页同样生效
接下来检查中文分类页。
可以看到分类：
编程语言
下的文章摘要同样已经完整展开。
例如：
A Tour of Go 中文翻译实录：如何只翻译教学代码注释，而不破坏 Go 代码
摘要能够完整介绍：
- 翻译页面；
- 教学代码注释保护；
- Go 标识符保护；
- 自动校验；
- 人工润色；
- 最终验证结果。
这也说明：
Type of Page → Archive
已经正确覆盖了分类归档页面。
不需要再分别为：
Category
Tag
Taxonomy
单独写 PHP 判断。
十、最终验证三：英文搜索结果同样完整显示
为了确认这套方案并不是只对中文有效，我又检查了英文站的搜索结果页。
搜索：
cloudflare
以后，可以看到英文文章摘要同样已经基本完整显示。
例如：
WordPress Homepage Still Shows Old Content After Publishing?
Testing EdgeOne and Cloudflare With a 2-Hour Cache for Homepage and Sitemap
下面的摘要已经可以完整介绍：
- W3 Total Cache；
- EdgeOne；
- Cloudflare；
- 首页和 Sitemap 的缓存时间；
- CDN 旧缓存问题；
- 最终的缓存策略调整。
第二篇关于 96 小时缓存优化的文章同样完整展示了较长英文摘要。
这意味着目前已经实际验证：
中文首页 ✓
中文分类页 ✓
英文搜索页 ✓
而这三类页面恰好对应现在配置的：
Homepage
Archive
Search Page
因此，这套配置已经形成了完整闭环。
十一、为什么主题中的 100 仍然保留？
虽然现在 WPCode 使用：
500
我并没有把主题编辑器中的：
100
重新改回 55。
原因是这样正好形成两层保护。
正常情况下：
WPCode 正常运行
↓
500
↓
已有摘要基本完整显示
如果以后某天因为：
- WPCode 临时停用；
- 插件升级；
- Snippet 出现异常；
- 调试过程中暂时关闭代码；
那么页面会自动回退到：
主题默认 100
而不是重新回到原来非常短的：
55
所以当前结构可以理解为：
第一层：
WPCode = 500
负责正常完整显示
第二层：
主题 = 100
负责异常情况下的合理降级
这样的维护方式反而更加稳妥。
十二、这次最大的经验：缓存环境下不要过早判断代码无效
这次过程给我留下最深印象的，并不是这几行 PHP。
真正值得记录的是：
在带有多层缓存的 WordPress 生产环境中，“刚修改代码以后立即刷新页面”并不一定能够准确证明代码是否生效。
尤其我的网站同时存在：
WordPress
W3 Total Cache
对象缓存
页面缓存
CDN
WPCode
PHP OPcache
当多层状态叠加以后，很容易出现：
代码已经修改
↓
立即刷新
↓
页面还是旧结果
↓
误以为代码无效
这次最终最有说服力的反而不是复杂诊断，而是最简单的长期对照：
启用 WPCode
→ 摘要完整
停用 WPCode
→ 回退到 100
重新启用
→ 再次完整
再加上几天后的：
中文首页
中文分类页
英文搜索页
实际结果验证，这才最终把因果关系确认下来。
十三、最终配置
目前这套摘要展示方案正式确定为：
WordPress 主题
Post Excerpt 最大字数：100
作为后备值。
WPCode
Snippet：
SWQ 列表页完整显示文章摘要
Code Type：
PHP Snippet
Insert Method：
Auto Insert
Location：
Frontend Conditional Logic
Enable Logic：
开启
Conditions：
Show
条件：
Homepage
OR
Archive
OR
Search Page
代码：
/**
* SWQ：列表页 Post Excerpt 尽量完整显示文章摘要。
*/
add_filter(
'render_block_data',
function ( $parsed_block ) {
if ( 'core/post-excerpt' === ( $parsed_block['blockName'] ?? '' ) ) {
$parsed_block['attrs']['excerptLength'] = 500;
}
return $parsed_block;
},
20
);
总结
这个需求的最终实现其实非常简单：
通过 WPCode，在指定列表页面渲染 Gutenberg
Post Excerpt区块时，把excerptLength提高到 500。
真正花时间的是验证过程。
经过最终的真实运行结果确认，目前：
中文首页 完整显示 ✓
中文分类页 完整显示 ✓
英文搜索页 完整显示 ✓
这也证明原来的技术方向并没有问题。
现在我更愿意把文章列表中的摘要理解成：
文章详情页之前的一次内容预览，而不是标题下面的一句装饰文字。
既然已经专门为文章准备了摘要，就应该尽可能让读者看到完整的信息，再决定是否进入详情页。
至此，这个从 55、100 到最终 500 的摘要显示问题，也终于可以正式结束了。
WordPress 网站维护、性能优化与博客运营咨询
本站已持续运营超过 10 年，累计发布 1000+ 篇原创技术文章，长期实践 WordPress 网站建设、CDN / Cloudflare 配置、缓存优化、Google SEO、广告变现和多语言网站运营。
如果你的 WordPress 网站遇到访问慢、缓存异常、插件冲突、广告不显示、SEO 基础结构混乱、CDN 配置不确定等问题，可以联系我做一次远程技术排查。
适合以下用户：
✅ 个人博客站长
✅ WordPress 网站运营者
✅ 独立开发者与内容创作者
✅ SaaS 产品官网运营团队
✅ 希望优化网站速度与稳定性的站点
服务内容：
✅ WordPress 速度优化
✅ Cloudflare / CDN / 缓存配置排查
✅ 插件冲突与页面异常排查
✅ AdSense 广告显示问题排查
✅ SEO 基础结构检查
✅ 博客运营与商业化咨询
如需了解方案或交流相关问题，请直接联系我，并注明：WordPress 维护咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复