应先验证前缀存在性，再分离并截取正文，最后拼接；中文/emoji需注意utf-16码元长度与显示宽度差异，后台用length，前端展示可选intl.segmenter或array.from。
substring 截取超长备注时前缀被意外截断？
直接用 substring 截取带前缀的字符串（如 "【审核中】用户提交了非常长的补充说明……"），容易把前缀本身切掉——因为没预留前缀长度，只按总长度硬截。关键不是“截多长”，而是“留给前缀多少空间”。
比如限制总长 30 字符，前缀 "【审核中】" 占 6 字符（UTF-16 下每个中文/符号算 1），那正文最多只能留 24 字符。硬写 str.substring(0, 30) 会把前缀后的内容直接砍断，甚至可能切在 "【审" 这种不完整状态。
正确计算起始与结束位置：先保前缀，再截正文
必须显式分离前缀和正文，再对正文单独截取。不能依赖 substring 的负数索引或模糊偏移。
- 先确认前缀是否真实存在：用
str.startsWith(prefix)判断，避免对无前缀字符串误操作 - 提取正文部分：用
str.slice(prefix.length)获取纯内容，比substring更安全（不处理负数逻辑） - 截取正文：用
content.substring(0, maxLength - prefix.length)，注意检查maxLength - prefix.length是否 ≤ 0 - 拼接结果：
prefix + truncatedContent，不额外加省略号——省略号属于 UI 层，不应污染数据层
中文、emoji、全角符号导致 length 计算不准？
String.prototype.length 返回的是 UTF-16 code unit 数，不是“人眼可见字数”。一个 emoji（如 "?"）或某些生僻汉字占 2 个 code unit，但显示为 1 个字符。若业务要求按“显示宽度”截断（如每行等宽渲染），length 就不可靠。
此时不要改用复杂 Unicode 库，先看场景：
- 后台存储/接口返回：坚持用
length，因 JSON、数据库字段长度限制均以 code unit 为准 - 前端展示截断：改用
Intl.Segmenter（现代浏览器）或简单 fallback 到slice(0, n)+trimEnd()防止空格截半 - 绝对要按视觉字符数？用
Array.from(str).slice(0, n).join('')，但注意性能——超长备注（>10KB）慎用
一行代码安全封装：带容错的截取函数
把上面逻辑收成可复用函数，重点处理边界：
function truncateWithPrefix(str, prefix, maxLength) {
if (typeof str !== 'string' || typeof prefix !== 'string') return str;
if (str.length const available = maxLength - prefix.length;
if (available <p>const content = str.slice(prefix.length);
const truncated = content.substring(0, available);
return prefix + truncated;
}</p>
调用示例：truncateWithPrefix("【驳回】材料缺失，请重新上传合同扫描件及法人身份证正反面", "【驳回】", 20) → "【驳回】材料缺失，请重"。注意它不会补 "…"，也不尝试智能断词——那是展示层该干的事。
真正容易被忽略的是：前缀本身可能含动态内容（如 "【{status}】"），这时必须先插值再截取；如果 status 是空字符串，前缀变成 "【】"，长度从 6 变成 2，硬编码前缀长度就会出错。
