Lodash 字符串方法怎么用，命名转换和截断有哪些坑？

Lodash 的字符串方法常用于命名转换、展示截断、首字母处理、模板拼接和简单匹配。它比原生字符串 API 更方便的地方在于：很多业务写法已经被封装成一个明确方法，比如 _.camelCase、_.kebabCase、_.upperFirst、_.truncate、_.deburr。不过它不是国际化文本处理库，遇到中文分词、复杂 emoji、富文本截断、多语言大小写规则时，仍然要谨慎。最合理的用法是把它放在工程化字符串处理中，比如接口字段转换、文件名清理、URL slug、列表摘要展示。

字符串处理最怕“看起来只是改个格式”，实际却影响了搜索、缓存或路由。比如 slug 生成规则一变，旧链接可能全部失效；字段命名转换不一致，接口数据就会悄悄丢字段。使用 Lodash 前最好确认转换结果是否会被持久化，是否需要兼容历史值。临时展示可以灵活一点，进入数据库、URL、配置文件的字符串规则就要稳定。

常用字符串方法怎么分类

命名转换包括 _.camelCase、_.snakeCase、_.kebabCase、_.startCase，适合在前后端字段、路由、文件名之间转换。首字母处理有 _.upperFirst 和 _.lowerFirst，常用于显示名称或生成类名。展示控制常用 _.truncate、_.padStart、_.padEnd、_.repeat，适合表格、日志和卡片摘要。清理和匹配有 _.trim、_.deburr、_.startsWith、_.endsWith、_.words、_.replace，适合做轻量预处理。

js
import _ from 'lodash';

function normalizeFieldName(label) {
  return _.camelCase(_.deburr(label));
}

function buildSlug(title) {
  return _.kebabCase(_.deburr(title));
}

function preview(text) {
  return _.truncate(_.trim(text), {
    length: 80,
    omission: '...'
  });
}

console.log(normalizeFieldName('Crème brûlée price'));
console.log(buildSlug('Lodash String Methods'));
console.log(preview('  这是一段很长的摘要文本，需要在列表里安全展示  '));

追问

_.camelCase、_.snakeCase、_.kebabCase 怎么选？

它们解决的是不同命名约定，不是谁比谁更高级。JavaScript 对象字段常用 camelCase，数据库字段和部分后端接口常见 snake_case，URL slug、CSS class、文件名更常用 kebab-case。取舍要跟上下游约定一致，不要在同一层里混用多套命名。踩坑点是缩写词会被重新拆分，像 APIResponse 可能变成 apiResponse，如果团队对缩写大小写有强约束，需要额外规则。

_.truncate 截断中文和 emoji 安全吗？

普通中文摘要大多数时候可用，但它不是完整的排版引擎。emoji、组合字符、富文本标签可能被截到不自然的位置，甚至造成显示异常。列表摘要、日志预览可以用 truncate，但聊天消息、富文本正文、多语言内容最好使用更专业的分段逻辑。边界判断很重要：如果截断结果会直接影响用户理解，就不要只按字符长度粗暴处理。

_.deburr 能处理中文拼音转换吗？

不能。_.deburr 主要处理拉丁字符里的重音符号，比如把 déjà vu 变成更接近 ASCII 的形式。它不会把中文转成拼音，也不会做分词。生成英文 slug 时它很有用，但中文标题要做拼音化，需要专门的拼音库。把 deburr 当成万能“去特殊字符”方法，是很常见的误用。

_.template 还值得在现代项目里用吗？

要看环境。简单字符串模板现在可以直接用 ES 模板字符串，前端视图层也通常交给 React、Vue、Svelte 这类框架。_.template 更适合老项目、非框架脚本、邮件或配置片段生成。它的坑是模板内容如果来自用户输入，必须考虑注入和转义问题；能用框架渲染或明确的模板引擎时，不要随手拼。

为什么有时不用 Lodash，直接用原生字符串方法更好？

如果只是 trim、startsWith、endsWith、replace 这类简单操作，原生方法已经足够清晰，也少一层依赖。Lodash 的优势在组合型命名转换和统一工具风格，而不是替代每个原生 API。实际取舍可以看代码意图：原生一眼能懂就用原生，Lodash 能明显减少样板代码再引入。过度使用工具库会让简单逻辑显得绕，也会增加新人查文档的成本。

还有一个细节是大小写转换会改变信息。用户输入、品牌名、专有名词并不总适合被统一处理成 start case 或 camel case。面向机器的字段名可以转换，面向人的文本要尊重原文。这个取舍如果没想清楚，页面上很容易出现看似整齐但不符合语境的文案。

测试字符串工具时，不要只测英文单词。至少补上空字符串、前后空格、连续分隔符、中文、带重音字符和 emoji。很多线上问题不是主路径错了，而是某个用户昵称、文件名或标题刚好踩到边界。字符串越靠近用户输入，越应该把这些奇怪样本提前放进测试里。

小结

Lodash 字符串方法最适合工程化文本处理：字段命名、slug、摘要、首字母、轻量清理。它能让常见转换写得短而稳定，但别把它当成国际化、富文本或安全模板的完整方案。字符串看似简单，真正的坑往往在边界字符和上下游约定里。