1. 字符串不是小儿科：先厘清"字符"与"编码"这两层地基
做开发的这十来年，我几乎每天都要和字符串打交道。前端传来的参数是字符串，后端返回的 JSON 是字符串，日志里躺着的一大半内容也是字符串。很多人觉得字符串 API 不就是 length、substring、split 那几下吗，真到了生产环境，一个中文乱码、一个空指针、一次 401 报错解析，就能让新手折腾半天。这篇 day10 的笔记，我不打算按官方文档把每个方法抄一遍，而是把这些年用字符串 API 时真正踩过的坑、验证过的方式、以及不同语言之间容易搞混的细节，按实际使用频率重新组织一遍。无论你用 Java、JavaScript 还是 Python，底层道理是相通的。
1.1 一个中文字符占几个长度：别被 length() 骗了
先说最基础也最容易出错的地方：length。几乎每门语言的字符串都有返回长度的 API，Java 是String.length()，JavaScript 是String.length属性，Python 是len()。但这里有个经典误区——Java 的length()返回的是 UTF-16 编码下的char数量，不是"用户眼里看到的字符个数"。
我自己就碰到过一个真实案例：调用某个大模型平台的 API 时，平台返回 400 错误，提示 "this model's maximum context length is 1048576 tokens"。当时我第一反应是"我传的消息没那么长啊"，后来把请求体打印出来一数，才发现是因为接口做了多层包装，元数据里的 system prompt、历史会话、工具定义全部累加，token 数是我肉眼估计的三倍。这个案例给我的教训是：估算字符串"长度"之前，必须先搞清楚你用的 API 到底按什么单位统计——是字符数、字节数、UTF-16 长度还是 token 数。
再举一个更常见的例子。String str = "abc中文";在 Java 里str.length()返回 5，因为"中文"两个字加上"abc"三个字符正好 5 个 char。如果这时候你以为外界传进来的也是 5，去做数据库字段长度校验，或者对截断位置做硬编码切片，分分钟出 bug。更隐蔽的是 emoji 和生僻字，比如"👍"在 Java 里是两个 char，JavaScript 的length也是 2，Python 的len()也是 2（除非是新版的 Python 配合length_by_unicode之类的方式）。"用户输入了一个表情符号，你按 2 个字符算错了位置"——这种问题你在企业微信昵称、评论内容、短信签名这类场景里会反复遇到。
那生产环境怎么办？我的经验是：凡是涉及对外显示、字数限制、截断展示的地方，不要直接用语言内置的 length，要么用 Unicode 码点计数，要么用你所在框架提供的"用户可见字符数"工具。Java 里可以用codePointCount，JavaScript 可以用Intl.Segmenter或者扩展字素簇的库。实在没有工具，宁可多留一点截断缓冲，也不要硬按 length 切。
1.2 下标、区间与边界：几乎所有 bug 都出在左闭右开
再说 substring 类的切片 API。Java 的substring(beginIndex, endIndex)是左闭右开，JavaScript 的substring和slice也是类似的区间语义，Python 的切片s[start:end]同样是 start 包含、end 不包含。规则本身不难，难的是人脑不习惯"结束位置不包含"这件事。
我见过很多新人在做字符串清洗时这样写：fileName.substring(fileName.lastIndexOf("."), fileName.length())，期望拿到的是从点号到末尾的扩展名。实际上如果lastIndexOf(".")返回 6，substring(6, 10)拿到的就是从下标 6 到 9 的内容，点号本身被包含进去了，所以拿到的可能是 ".pdf" 这种带点结果。想清楚左闭右开之后，要么lastIndexOf(".") + 1作为起始，要么直接用substring(lastIndexOf("."))这个单参数重载。类似的坑在 Python 里也存在，s[s.index('.') + 1:]才是正确姿势。
还有一个边界问题是"找不到时的返回值"。Java 的indexOf找不到返回 -1，JavaScript 也是 -1，Python 的find返回 -1，但index会抛异常。我建议所有用到查找类 API 做切片前，先把 -1 分支处理掉，不要假设"一定能找到"。比如憨憨写法url.substring(url.indexOf("?"))，一旦 URL 没有参数，indexOf("?")返回 -1，substring(-1)在 Java 里直接抛StringIndexOutOfBoundsException，在 JavaScript 里返回的是最后一个字符——两种行为天差地别，但都会让你的程序行为变异。
2. 相等性判断：equals、==、compareTo 的三角关系
字符串比较是使用频率最高的操作之一，也是跨语言时最容易踩坑的地方。Java 和 JavaScript 都有==和"内容比较"方法的区分，Python 则只有==。很多从 Python 转 Java 的人，第一周就会在字符串比较上翻车。
2.1 == 比的是引用，不是内容：从常量池说起
Java 里str1 == str2比较的是两个引用是否指向同一个对象，而不是内容是否相同。为什么写"abc" == "abc"有时返回 true？因为编译期字符串常量会放到常量池，两个相同字面量复用了同一个实例。但只要你有一个字符串来自变量拼接、来自new String(...)、来自接口返回，==的结果就不可预测了。
我见过最经典的 bug 是这样：if (status == "SUCCESS")在本地测试时一切正常，因为常量池复用让这个比较返回 true；等到代码部署到生产，status 从 HTTP 响应体里解析出来后，==变成 false，线上报错一片。排查到的第一时刻，整个人是懵的。这个问题的根治方案只有一个：Java 一律用equals，两个对象都不确定非空时用Objects.equals。
JavaScript 里其实也有类似问题，不过表现不同。"1" == 1为 true 是因为隐式类型转换，"1" === 1为 false 是因为严格相等。"严格相等"听起来更安全，但字符串比较时还要留个心眼：如果两个操作数本身一个是字符串对象（new String）一个是原始字符串，===也会返回 false。ESLint 规则里通常建议禁用new String，直接用字面量，就是不想让大家碰到这个冷门对象坑。
2.2 忽略大小写与区域敏感：用户不按 ASCII 出牌
忽略大小写比较，Java 有equalsIgnoreCase，JavaScript 是先把两边toLowerCase()再比较，Python 是s1.lower() == s2.lower()。看似简单，但这里面有个区域敏感问题：土耳其语里大写I对应的小写是ı（无点 i），不是 ASCII 的i。如果你用 JavaScript 的toLowerCase()处理土耳其语用户输入的文件名后缀，.PDF可能变成.pdf，也可能变成另一个字符，导致文件匹配失败。Java 的equalsIgnoreCase内部用的是区域无关规则，相对稳，但toLowerCase(Locale.getDefault())就会踩区域坑。
我的建议是：凡是要做统一格式化的场景（邮箱、网址、哈希值、枚举值），统一用区域无关的方法，Java 里就是toLowerCase(Locale.ROOT)，JavaScript 里如果业务真涉及非英语区域，可以考虑toLocaleLowerCase('en-US')这类固定区域写法。别指望用户和你的环境变量都乖乖用 en-US。
2.3 排序用 compareTo，别自己写减法
字符串排序乍一看很简单，但"按什么序"其实大有学问。Java 的String.compareTo按 Unicode 码点逐字符比较，JavaScript 的localeCompare按语言区域规则比较，Python 直接比较 Unicode 码点。生产环境里最常见的排序错误是拿字符串存了数字，然后想按数字大小排。比如 ID 是 "10"、"9"、"2"，按字典序排出来是 "10"、"2"、"9"，按数字序排是 "2"、"9"、"10"。这不是字符串 API 的锅，是业务语义没想清楚。
另外，compareTo返回的整数就是差值，有人喜欢偷懒写return s1.compareTo(s2)做排序比较器，这是对的。但千万别自己写return s1.charAt(0) - s2.charAt(0)，因为 char 相减可能出现整数溢出之外的问题——虽然字符串比较的场景很少溢出，但一旦遇到代理对字符，你拿到的根本不是"逻辑字符"。用官方提供的compareTo/localeCompare，语义清晰，还省得你处理奇奇怪怪的编码边角。
3. 切割与拼接：split、join 的一进一出都有坑
字符串拆分和拼接，是 API 调用、日志解析、CSV 处理、URL query 参数解析里最常用的操作。常规用法大家都会，但细节坑一挖一个准。
3.1 split 默认会丢弃尾部空串：最容易被忽略的行为
Java 的"a,b,,,".split(",")返回的是["a", "b"]，而不是["a", "b", "", "", ""]——split 默认把所有尾部空串丢掉了。JavaScript 的可选参数split(separator, limit)是另外一套语义，"a,b,,,".split(",")返回的是包含空串的完整数组。这俩行为不一致，如果你在前后端各写一半逻辑，两边数据对不上，排查起来非常痛苦。
比如你解析一行 CSV：姓名,城市,备注，最后那个备注可能是空的。Java 里line.split(",")会直接丢掉最后一个空字段，导致数组长度比预期少 1，你按fields[2]取值时就数组越界。解决方法是用split(",", -1)这个重载，负数的 limit 表示保留全部空串。这个知识点文档里写得有，但大多数人没真正记在心里，直到线上报错。
3.2 正则元字符要转义：点号、竖线这些"老朋友"
Java 和 JavaScript 的split接受的是正则表达式，不是普通字符串。这意味着你想按.分割"2024.01.15"时，直接split(".")会得到一个空数组，因为正则里.代表任意字符，整个字符串从头到尾任何一个位置都能匹配上。同样的道理，竖线|、反斜杠\\、方括号[、括号(全是正则元字符，都要写成split("\\.")、split("\\|")、split("\\\\")。
Python 的标准库split是普通字符串语义不受这个影响，但一旦你用re.split，同样的问题又回来了。我个人的习惯是：只要用到了 split 且分隔符不是字母数字，就先问自己一句"这个分隔符在正则里有特殊含义吗"。宁可多写两个转义符，也不要等报错再来想。
3.3 大量拼接别用 +=：StringBuilder 的真实收益
拼接字符串是性能话题里的老常客。Java 里String是不可变对象，每次+=都会创建一个新字符串，循环 10 万次就是 10 万个中间对象，GC 压力肉眼可见。虽然现在的 JVM 对+=做了不少优化，但循环内拼接的字节码还是会反复创建StringBuilder再toString，没必要。我的经验是：循环内或高频路径上，一律先声明一个StringBuilder，最后toString()。
JavaScript 这边的历史包袱不太一样，老版本 IE 用数组push+join拼接，后来 V8 引擎优化了+=，现代代码直接模板字符串就好了。Python 则推荐''.join(list)而不是+=，因为字符串不可变，循环+=的时间复杂度会退化。
拼接还有一层语义坑：null 会变成字符串"null"。Java 里String.valueOf(null)返回字面量"null"，null + "abc"也得到"nullabc"。所以拼日志、拼 SQL、拼 URL 时，如果某一段可能是 null，要么提前判空，要么用专门的方法兜底。我自己写工具类时都会有一个nullToEmpty的习惯，从根上避免意外拼接出"null"字符串。
4. 转换类 API：数字互转、编码、JSON 序列化的真实使用场景
字符串和数字、字节数组、JSON 之间的相互转换，是调用第三方 API 时绕不开的环节。每次对接接口，基本就是"收字符串、解析字符串、拼字符串"这三板斧。
4.1 字符串转数字：parseXxx 的异常和空值处理
Java 里Integer.parseInt("123")得到 123，但Integer.parseInt("12.3")直接抛NumberFormatException，parseInt(null)也抛。JavaScript 里parseInt("12.3")返回 12，parseInt("abc")返回 NaN，Number("12.3")和parseInt又不一样。Python 的int("12.3")会抛ValueError。三个语言三种语义，跨端联调时特别容易鸡同鸭讲。
我最想强调的是：任何来自用户输入、配置文件、外部 API 的字符串，在转数字前必须走一遍防御逻辑。先判空、再 trim、最后捕获异常，三步缺一不可。别迷信"这个字段是后端返回的数字，一定不会错"，我见过因为字段类型从 number 变成 string 导致前端parseInt后 NaN 的线上事故，也见过 Java 侧因为" 123 "带空格没 trim 导致转换失败的案例。另外，金额、ID 这类大数场景，Java 里用Long.parseLong都可能溢出，必要时得用BigDecimal或字符串原样传递。
4.2 数字转字符串：三种写法怎么选
数字转字符串，Java 里有String.valueOf(100)、Integer.toString(100)和100 + ""三种常见方式。功能上等价，但String.valueOf(null)返回"null"而不是空指针，这点在实际写日志时很友好；+ ""虽然写法最随意，但在 IDEA 里总会被提示有更优写法。我的建议是：工具类里统一用String.valueOf，因为它对 null 有明确的语义处理，代码复审的人一眼就能看出你不会踩 NPE。
JavaScript 里String(100)、100.toString()（其实要写(100).toString()）、'' + 100也是三套。Python 则是str(100)和 f-string。这些差别不痛不痒，但团队协作时最好约定一种统一写法，减少 review 时的精神摩擦。
4.3 中文乱码的根源：getBytes 与 charset 的坑
字符串和字节数组互转，是乱码问题的核心源头。Java 的getBytes()无参版本用平台默认字符集，Windows 上可能是 GBK，Linux 上通常是 UTF-8。同一段代码在本地没问题，部署到 Linux 上中文全乱，这是老程序员都见过的经典事故。对策只有一个：所有编码转换场景，显式指定字符集，getBytes(StandardCharsets.UTF_8)、new String(bytes, StandardCharsets.UTF_8)。JavaScript 里Buffer.from(str, 'utf8')，Python 里'str'.encode('utf-8')，同样是这个原则——永远不要依赖运行环境的默认值。
调用大模型 API 时尤其要注意：如果请求体里的中文经过URLEncoder.encode（Java 里默认按表单规则编码，空格会变+），服务端如果按 strict RFC 规则解码，有可能得到错误结果。我一般用URLEncoder.encode(str, StandardCharsets.UTF_8)之后，再把+手动替换成%20，或者干脆用专门的 HTTP 客户端库，不要自己拼 URL。
4.4 JSON 与字符串：序列化不是简单 toString
把对象转成 JSON 字符串再传给 API，是前后端对接的日常操作。新手最容易犯的错是：user.toString()得到的是一堆内存地址风格的字符串（Java 里没重写 toString 的话），根本不是 JSON。正确做法是用序列化库——Java 的 Jackson / Gson，JavaScript 的JSON.stringify，Python 的json.dumps。
这里有两个字符串相关的坑值得说。第一，JSON.stringify遇到undefined属性会直接丢字段，遇到NaN会变成null，如果你对接的接口对字段完整性要求高，必须自己预处理数据。第二，Java 侧用 Gson 序列化时，如果对象里有循环引用，会抛异常或导致栈溢出；Jackson 则默认会序列化getter，有时候你只是想在对象里加一个计算用的getXxx()，结果接口返回里多出个xxx字段，把对方搞得很困惑。处理方式是在字段或 getter 上加@JsonIgnore。
5. 逆序、排序与子串搜索：来自面试题和生产环境的双重验证
字符串逆序、字符串数组排序、查找子串，看起来特别像面试题，但生产环境里它们的变体无处不在。比如日志脱敏要逆序截取，文件名排序要忽略部分前缀，敏感信息过滤要查子串。
5.1 字符串逆序：三种实现与性能对比
面试官爱问"怎么把字符串逆序"，其实考察的是你对不可变对象和字符数组的理解。我知道的实现至少有三种：
第一种，Java 直接new StringBuilder(str).reverse().toString()。这是最简单的方式，API 原生支持，代码量最少，日常业务完全够用。第二种，自己转成char[]然后双指针交换，适合面试展示思路，但生产代码里没必要重复造轮子。第三种，从尾部遍历用charAt拼接，这里就要注意循环里别用+=，否则性能会退化。
真正生产环境里我遇到的逆序需求往往不是"整个字符串反转"，而是"从后往前找某个分隔符"。比如从日志行里找出最后一个逗号后面的内容，正确做法不是把所有字符反转，而是lastIndexOf配合substring。这里想提醒的是：别因为"逆序"两个字就把数据整个倒过来，语义上你要的可能只是"从尾部查找"。
5.2 排序是"按字典序"还是"按数字序"：先想清楚语义
字符串数组排序也同样。文件名排序、版本号排序、IP 排序，如果直接调用Arrays.sort，你会发现"10"排在"2"前面。这不是 bug，是字典序的预期行为，但业务上通常不是你要的。版本号排序是最典型的场景："1.10.0"和"1.9.0"，按字典序"1.10.0"在前，按版本语义"1.9.0"在前。
解决方案是自定义比较器：把字符串按.拆分成数字数组，逐段比较。这个拆解过程又会回到第 3 节的 split 坑——版本号里可能有不规则的段数，要先补齐再比较。类似地，IP 地址排序也可以转成长整型比较。总之，碰到"看起来像数字的字符串排序"，先做语义转换，再排序，最后转回字符串展示。这三个步骤里每一步都可能用到字符串 API，所以它们永远是一套组合拳。
5.3 indexOf/contains 与更高级的查找需求
子串查找，Java 有contains、indexOf、startsWith、endsWith，JavaScript 有includes、indexOf、startsWith、endsWith，Python 有in、find、startswith、endswith。常规使用没问题，但要注意大小写敏感是默认行为。做敏感词过滤、邮箱域名校验时，很多人忘了先统一大小写，导致 "Admin@Example.com" 和 "admin@example.com" 匹配不上。
更高级的查找需求，比如按模式匹配、提取捕获组，就要用到正则 API 了。Java 的Pattern.compile(...).matcher(...)比每次直接matches更高效，因为正则编译很贵。如果你在一个循环里对 10 万条日志做正则提取，每次都用str.matches("复杂正则")，性能会差出好几个数量级。正确做法是把Pattern提出来做静态字段。这个优化细节，线上压测时直接能把接口耗时从 800ms 降到 200ms。
6. 生产环境真实踩坑记录：从日志里学 API 细节
最后这部分，我挑几个真实的线上排查记录，算是把前面所有 API 细节串一遍。你会发现，很多事故的根因并不是"别人接口有问题"，而是自己对字符串 API 的行为预期和实际不一致。
6.1 API Key 校验失败的 401 报文：先别急着怀疑服务端
对接外部 API 时，返回 401 Unauthorized 的错误信息往往长这样：unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****。大多数人的第一反应是"我的 key 是不是过期了"、"服务端是不是抽风了"，点开日志去翻 key 配置。但我的排查习惯是先用字符串 API 对报错做一次切片分析。
先把:后面的sk-svcac****截出来，和前一天的 key 做比较，确认前缀一致；再用startsWith检查 key 是否带了引号或空格。我至少遇到两次这样的情况：配置文件里复制 key 时带了一个不可见空格，代码里没有trim()，服务端拿到" sk-xxx"自然认为 key 不正确。解决方式看起来朴素得可笑——在读取配置后统一trim()。但就是这个trim()，能救回一晚上的排查时间。
另一个容易忽略的点是对 API key 做脱敏展示。日志里明文打印完整 key，会导致安全风险。我的习惯是：写一个脱敏工具，只保留前几位和后四位，中间用****代替，思路其实就是substring(0, 7) + "****" + substring(len-4)。注意这里的substring边界要算准，不然脱敏后的字符串长度不对，事后对 key 做比对时会怀疑人生。
6.2 内存泄漏不是字符串的锅，却是拼接方式的锅
网上搜"MFC 字符串内存泄漏"、"Java 内存泄漏"，一排排的帖子，很多最后都指向字符串处理。其实字符串本身不可变，不会主动泄漏，真正的锅往往在"持有不可变对象的容器长期不释放"或者"循环内制造大量中间字符串"。
我调过一个线上问题：每日定时任务把几百万条记录拼成一个大字符串上传，内存持续增长，老年代占比一直往上涨。定位后发现，代码里用+=在循环里拼接，每条记录还做了JSON.toJSONString再拼上换行符，几百万个中间字符串把堆塞满了。修复方案很简单：改用StringBuilder，并且在每批 1000 条后把缓冲字符串置空。这个改动之后，任务内存曲线直接平稳了。说这个案例是想强调：字符串 API 本身没错，但你要知道每个 API 调用背后会分配多少对象，频繁调用的路径上，任何+=、split、toUpperCase都可能成为性能瓶颈。
6.3 用字符串 API 解析真实日志的完整过程
最后展示一个我经常做的日志解析动作。假设有一行原始日志：2025-01-15 10:23:45 ERROR [http-nio-8080-exec-3] com.example.OrderService - orderId=10086, userId=9527, msg=连接超时。要从中提取 userId，我会这样拆：
第一次split(" - ", 2)把时间戳和线程部分拆开，拿到[http-nio-8080-exec-3]和后面的业务消息。注意这里的-有特殊含义吗？没有，所以 split 可以直接用。接着从业务消息里用indexOf("userId=")定位，再用substring截取到下一个逗号位置。这里有个细节：如果消息本身里也包含userId=，你会截错，所以更稳妥的做法是contains("userId=")不满足再改正则提取。整个解析过程不过五六行代码，但每一步都在用split、indexOf、substring、contains这些最基础的字符串 API。很多人觉得这些东西太基础不值得写，实际上正是这些基础方法的边界行为，决定了你的日志解析程序在异常数据面前是崩溃还是容错。
我在实际开发里的一个体会是：写字符串处理代码时，脑子里要同时装着"正常数据长什么样"和"异常数据会怎么破坏我的假设"。日志里的字段偶尔缺失、顺序偶尔变化、值里偶尔带着分隔符，这些都是常态。宁可多写一个守卫条件，多用一个-1判断，也不要让整个链路因为一行解析代码抛异常。字符串 API 没有银弹，熟练就是靠一次次踩坑换来的。
