本文详解 Freemarker 内置 truncate_c 在空终止符（''）场景下的实际截断逻辑，解释为何结果偏离直觉，并提供安全、可控的替代方案（如子串切片 [] 语法和自定义宏），帮助开发者避免隐式空格处理导致的长度偏差。
本文详解 freemarker 内置 `truncate_c` 在空终止符（`''`）场景下的实际截断逻辑，解释为何结果偏离直觉，并提供安全、可控的替代方案（如子串切片 `[]` 语法和自定义宏），帮助开发者避免隐式空格处理导致的长度偏差。
Freemarker 的 truncate_c 内置函数设计初衷是“按字符截断”，以更贴近指定长度——不同于 truncate（仅在词尾截断），truncate_c 允许在任意字符位置切断。但其行为在使用空字符串 '' 作为终止符时存在易被忽略的隐式处理逻辑：即使 terminator 长度为 0，FreeMarker 仍会尝试在截断点附近“美化”输出——例如，若截断恰好落在单词边界后（如空格前），它会主动移除末尾空格并可能重新插入一个空格（用于视觉对齐），这直接导致最终长度不可控。
以问题中的示例为例：
<#assign myField = "1234 SOMESTREETSSS AVE NE 123">
${myField?truncate_c(25, '')}字符串总长为 31 字符。期望截取前 25 个字符得到 "1234 SOMESTREETSSS AVE NE"（注意末尾是 E，其后为空格），但实际输出为 "1234 SOMESTREETSSS AVE N"（末尾是 N）。原因在于：truncate_c 并非简单取 [0..24]，而是先定位第 25 位（即索引 24，对应字符 'E'），再向后检查上下文——发现 'E' 后紧跟空格 ' '，于是触发“边界清理”逻辑：移除该空格，并因终止符为空，本不应补空格；但旧版本（
✅ 推荐解决方案：使用子串切片（最可靠）
当需要严格按字符数截断且不引入任何修饰逻辑时，应放弃 truncate_c，改用原生子串语法：
${myField[0 ..* 25]}[0 ..* n] 表示从索引 0 开始，取 n 个字符（左闭右开），完全无副作用。上例中将精确返回前 25 字符："1234 SOMESTREETSSS AVE NE"（注意末尾空格被保留，符合原始字符位置）。
⚠️ 注意事项：
- 确保字符串长度 ≥ 截取长度，否则会抛出
TemplateException。可加安全判断：${myField?length >= 25 ? then(myField[0 ..* 25], myField)} - 若需兼容超长文本 + 自动添加省略号（如
"..."），建议封装为自定义宏，明确控制逻辑：
<#macro safeTruncate text len suffix="">
<#local truncated = text[0 ..* len]>
<#if text?length > len>
${truncated}${suffix}
<#else>
${truncated}
</#if>
</#macro>
<@safeTruncate text=myField len=25 suffix="…"/>? 总结：truncate_c 不是 bug，而是面向“人类可读性优化”的设计，在空 terminator 场景下易引发误解。*对确定性长度要求高的场景（如字段对齐、API 输出限制），务必使用 `[0 .. n]切片；对展示层美化有需求的场景，可升级至 Freemarker 2.3.33+ 并结合非空 terminator（如"…"`）获得更可预测的行为。**
