1. 字符串不是小儿科先厘清字符与编码这两层地基做开发的这十来年我几乎每天都要和字符串打交道。前端传来的参数是字符串后端返回的 JSON 是字符串日志里躺着的一大半内容也是字符串。很多人觉得字符串 API 不就是 length、substring、split 那几下吗真到了生产环境一个中文乱码、一个空指针、一次 401 报错解析就能让新手折腾半天。这篇 day10 的笔记我不打算按官方文档把每个方法抄一遍而是把这些年用字符串 API 时真正踩过的坑、验证过的方式、以及不同语言之间容易搞混的细节按实际使用频率重新组织一遍。无论你用 Java、JavaScript 还是 Python底层道理是相通的。1.1 一个中文字符占几个长度别被 length() 骗了先说最基础也最容易出错的地方length。几乎每门语言的字符串都有返回长度的 APIJava 是String.length()JavaScript 是String.length属性Python 是len()。但这里有个经典误区——Java 的length()返回的是 UTF-16 编码下的char数量不是用户眼里看到的字符个数。我自己就碰到过一个真实案例调用某个大模型平台的 API 时平台返回 400 错误提示 this models 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 里是两个 charJavaScript 的length也是 2Python 的len()也是 2除非是新版的 Python 配合length_by_unicode之类的方式。用户输入了一个表情符号你按 2 个字符算错了位置——这种问题你在企业微信昵称、评论内容、短信签名这类场景里会反复遇到。那生产环境怎么办我的经验是凡是涉及对外显示、字数限制、截断展示的地方不要直接用语言内置的 length要么用 Unicode 码点计数要么用你所在框架提供的用户可见字符数工具。Java 里可以用codePointCountJavaScript 可以用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(.)返回 6substring(6, 10)拿到的就是从下标 6 到 9 的内容点号本身被包含进去了所以拿到的可能是 .pdf 这种带点结果。想清楚左闭右开之后要么lastIndexOf(.) 1作为起始要么直接用substring(lastIndexOf(.))这个单参数重载。类似的坑在 Python 里也存在s[s.index(.) 1:]才是正确姿势。还有一个边界问题是找不到时的返回值。Java 的indexOf找不到返回 -1JavaScript 也是 -1Python 的find返回 -1但index会抛异常。我建议所有用到查找类 API 做切片前先把 -1 分支处理掉不要假设一定能找到。比如憨憨写法url.substring(url.indexOf(?))一旦 URL 没有参数indexOf(?)返回 -1substring(-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 有equalsIgnoreCaseJavaScript 是先把两边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 用数组pushjoin拼接后来 V8 引擎优化了现代代码直接模板字符串就好了。Python 则推荐.join(list)而不是因为字符串不可变循环的时间复杂度会退化。拼接还有一层语义坑null 会变成字符串null。Java 里String.valueOf(null)返回字面量nullnull abc也得到nullabc。所以拼日志、拼 SQL、拼 URL 时如果某一段可能是 null要么提前判空要么用专门的方法兜底。我自己写工具类时都会有一个nullToEmpty的习惯从根上避免意外拼接出null字符串。4. 转换类 API数字互转、编码、JSON 序列化的真实使用场景字符串和数字、字节数组、JSON 之间的相互转换是调用第三方 API 时绕不开的环节。每次对接接口基本就是收字符串、解析字符串、拼字符串这三板斧。4.1 字符串转数字parseXxx 的异常和空值处理Java 里Integer.parseInt(123)得到 123但Integer.parseInt(12.3)直接抛NumberFormatExceptionparseInt(null)也抛。JavaScript 里parseInt(12.3)返回 12parseInt(abc)返回 NaNNumber(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 上可能是 GBKLinux 上通常是 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.encodeJava 里默认按表单规则编码空格会变服务端如果按 strict RFC 规则解码有可能得到错误结果。我一般用URLEncoder.encode(str, StandardCharsets.UTF_8)之后再把手动替换成%20或者干脆用专门的 HTTP 客户端库不要自己拼 URL。4.4 JSON 与字符串序列化不是简单 toString把对象转成 JSON 字符串再传给 API是前后端对接的日常操作。新手最容易犯的错是user.toString()得到的是一堆内存地址风格的字符串Java 里没重写 toString 的话根本不是 JSON。正确做法是用序列化库——Java 的 Jackson / GsonJavaScript 的JSON.stringifyPython 的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、endsWithJavaScript 有includes、indexOf、startsWith、endsWithPython 有in、find、startswith、endswith。常规使用没问题但要注意大小写敏感是默认行为。做敏感词过滤、邮箱域名校验时很多人忘了先统一大小写导致 AdminExample.com 和 adminexample.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 - orderId10086, userId9527, msg连接超时。要从中提取 userId我会这样拆第一次split( - , 2)把时间戳和线程部分拆开拿到[http-nio-8080-exec-3]和后面的业务消息。注意这里的-有特殊含义吗没有所以 split 可以直接用。接着从业务消息里用indexOf(userId)定位再用substring截取到下一个逗号位置。这里有个细节如果消息本身里也包含userId你会截错所以更稳妥的做法是contains(userId)不满足再改正则提取。整个解析过程不过五六行代码但每一步都在用split、indexOf、substring、contains这些最基础的字符串 API。很多人觉得这些东西太基础不值得写实际上正是这些基础方法的边界行为决定了你的日志解析程序在异常数据面前是崩溃还是容错。我在实际开发里的一个体会是写字符串处理代码时脑子里要同时装着正常数据长什么样和异常数据会怎么破坏我的假设。日志里的字段偶尔缺失、顺序偶尔变化、值里偶尔带着分隔符这些都是常态。宁可多写一个守卫条件多用一个-1判断也不要让整个链路因为一行解析代码抛异常。字符串 API 没有银弹熟练就是靠一次次踩坑换来的。