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 行为、空值风险和上下文语义。
