es-toolkit 截断文本报正则错误，分隔符却只是问号

把文本预览按问号附近截断，调用的是 es-toolkit/compat 的 truncate，结果却报 Invalid regular expression 或 Nothing to repeat。如果 separator 明明传的是字符串 '?'，应检查是否使用了 1.52.0 的实现。

这一版本会把字符串分隔符直接插入内部正则。问号、加号、左方括号等字符因此被解释成正则语法，而不再是原来要找的字面分隔符。

字符串被错误地当成正则片段

下面是对应的调用形态：

import { truncate } from 'es-toolkit/compat';

const preview = truncate('hello world? how are you doing today?', {
  length: 20,
  separator: '?',
});

在受影响实现中，separator 会进入 new RegExp。问号没有可修饰的前项，可能立即抛 SyntaxError；左括号或方括号可能造成未闭合分组。点号更隐蔽，它可以形成合法正则，却匹配任意字符，导致截断位置不符合字面分隔符约定。

因此，没有抛异常也不证明其他标点结果正确。先确认导入入口是 es-toolkit/compat、实际安装版本是 1.52.0，以及最终传入的 separator 类型。原生字符串截断、Lodash 自己的实现和主动传入 RegExp，是不同路径。

正式 1.53.0 会转义字符串分隔符

正式 es-toolkit 1.53.0 对非 RegExp 的 separator 调用 escapeRegExp，再构建内部表达式。这个处理保留字符串的字面含义；真正的 RegExp 仍使用它的 source 与相应 flags。

命中 1.52.0 条件时，可以沿项目的依赖更新流程采用 1.53.0，核对锁文件和实际 bundle 解析的版本。保留原本的字面字符串即可，不需要为了适配新实现给问号额外加反斜杠。

如果应用曾经对字符串 separator 预先做过正则转义，升级后需要重新核对：字符串现在会由库转义，业务再传入 '\\?'，表达的可能已经是带反斜杠的文本，而不是一个问号。

暂不能升级时，只在受影响调用点评估替代方案。不能把任意用户字符串直接放进 RegExp 构造器；也不宜为一次截断报错整体切换字符串处理库而不核对 Unicode、长度和省略号规则。

不要与零宽正则卡死混在一起

这个问题的触发条件是“字面字符串被解释为正则语法”。另一类故障是实际传入了会零宽匹配的 RegExp，库内循环没有推进；两者的机制与处理不同。给字面问号加 g 标志、调整线程超时，都不能补上这里缺失的转义。

更新后应检查问号、加号、括号、点号、普通空格、没有分隔符，以及分隔符位于截断边缘的文本。对比长度与省略号是否仍符合界面要求；异常消失之外，还要确认点号没有继续在任意字符处分割。