怎么通过 toLowerCase() 和 toUpperCase() 转换字母大小写

苏承栈

2026-09-29 • 👁 0人浏览过

toLowerCase()和toUpperCase()不修改原字符串，仅返回新字符串；需接收返回值，防范null/undefined及Unicode locale差异，避免链式调用崩溃。字符串大小写转换的基本行为

toLowerCase()

和

toUpperCase()

是 JavaScript 字符串的原生方法，它们不修改原字符串，而是返回新字符串。这点容易被忽略——如果你没接住返回值，看起来就像“没生效”。常见错误现象：

str.toLowerCase(); console.log(str);

输出仍是原样，因为没赋值。必须用变量接收结果，例如：

const lower = str.toLowerCase();

对

null

或

undefined

直接调用会报

TypeError: Cannot read property 'toLowerCase' of null

数字、布尔值等非字符串类型调用前需显式转字符串，否则可能得到意外结果（如

(123).toString().toLowerCase()

）处理非 ASCII 字符时的坑默认情况下，这两个方法按 Unicode 基础规则转换，但在土耳其语、希腊语等 locale 下，

i

→

I

或

İ

的映射并不一致。比如在土耳其 locale 中，

"i".toUpperCase()

"İ"

（带点大写 I），而非

"I"

。如果你的应用面向多语言用户，或处理用户输入的姓名、地名等，建议显式指定 locale：

"istanbul".toLocaleUpperCase("tr-TR")

→

"İSTANBUL"

"hello".toLocaleLowerCase("en-US")

更明确，但通常英文环境用

toLowerCase()

就够用注意：不是所有浏览器都支持多 locale 参数，旧版 Safari 可能忽略第二个参数性能与链式调用注意事项这两个方法本身很快，但频繁调用或在循环中反复转换同一字符串，可能暴露隐性开销。更关键的是链式调用时的可读性与容错问题。避免嵌套过深：

str.trim().toLowerCase().replace(/[^a-z0-9]/g, "")

是常见模式，没问题；但若中间某步可能返回

undefined

（比如取对象属性后调用），就会崩推荐加防护：例如

(input || "").toLowerCase()

或用可选链 + 空值合并：

obj?.name?.toLowerCase() ?? ""

不要为“节省一次赋值”而写

if (str.toLowerCase() === "yes") {...}

—— 每次比较都新建字符串，对长字符串或高频判断不友好和正则 / CSS / HTML 场景的配合误区大小写转换常被用在搜索过滤、表单校验、类名生成等场景，但容易混淆“谁该负责转换”。前端搜索时，别只靠

toLowerCase()

做模糊匹配——中文、emoji、全角字符不受影响，且无法替代正则的

i

标志；更稳妥是统一转小写再用

includes()

或正则

/keyword/i

CSS 类名生成慎用：比如

camelCaseToKebab

后再

toLowerCase()

，但要注意已有大写字母如

"XMLHttp"

转成

"xmlhttp"

会丢失语义，此时应结合

String.prototype.replace()

处理边界 HTML 属性值（如

data-*

）不区分大小写，但 DOM API（如

dataset

）自动转为 camelCase，这时手动调用

toUpperCase()

反而破坏约定实际用得多的其实是防御性写法和 locale 意识，而不是函数本身有多难。真正卡住人的，往往是“以为它只是简单替换”，却没意识到 Unicode 行为、空值风险和上下文语义。

相关文章