企业官网建设流程全解析

“String s = new String("abc")到底创建了几个对象”，这道题我面试过别人不下五十次，能答对的不到三成。但说实话，我从来不觉得这是道好题——它考察的不是背答案，而是对Java字符串底层机制有没有真正思考过。字符串操作是Java开发里最基础也最高频的动作，偏偏越基础的东西，越容易在关键时刻掉链子：线上日志打出来全是乱码、用split切分数据莫名其妙丢元素、循环里用加号拼字符串把接口拖垮。这篇文章我把这些年踩过的坑和沉淀下来的经验一次性讲透，从底层原理到实操细节，再到面试真题解析，覆盖字符串操作的方方面面。适合刚入门想打牢基础的初学者，也适合准备面试想要系统梳理的求职者，老手如果能在里面捞到一两个平时没注意的细节，那也算值了。

1. 从String不可变性开始理解Java字符串

1.1 为什么String要被设计成不可变

String在Java里被设计成final类，内部存放字符的数组也是final的——这意味着一个字符串对象创建之后，它的内容就再也没有办法被修改。这不是拍脑袋决定的，背后有非常实际的设计考量。

第一个好处是线程安全。不可变对象天然可以在多线程环境下共享，不需要任何同步措施。String被大量用作HashMap的key、日志输出的消息、配置项的取值，如果它是可变的，并发场景下数据随时可能被意外篡改，整个系统的稳定性就无从谈起。

第二个好处是字符串常量池能正常工作。正因为字符串不可变，JVM才能放心地把相同内容的字符串引用指向同一个对象。如果字符串可变，常量池里的对象被某处修改，所有引用它的地方都会跟着变，那简直是一场灾难。缓存、池化的基础，就是对象内容不可变。

第三个好处是hashCode可以安全地缓存。String重写了hashCode方法，并且把计算出的哈希值缓存在成员变量里，第一次调用时计算，之后直接返回。这依赖不可变性——内容不会变，哈希值自然也就不用重新计算。这也是String能成为HashMap最常用key的原因之一。

有个细节值得一提：在Java 8及以前，String内部用char[]存储；从Java 9开始，改成了byte[]加一个编码标志位coder，这是JEP 254引入的Compact Strings优化。纯Latin-1字符的字符串每个字符只占一个字节，比原来节省一半内存。这就是为什么你在Java 9及以上版本的线上环境里，用反射去查看String内部字段，看到的是byte数组而不是char数组。

1.2 字符串常量池：字面量与new的本质区别

字符串常量池，英文叫String Constant Pool，是JVM运行时数据区里一块特殊的内存区域。JDK 7之前它在永久代里，JDK 7开始移到了Java堆中。这也是当年经常出现的PermGen OutOfMemoryError在字符串场景下彻底消失的原因——永久代的空间固定且很小，大量字符串驻留很容易撑爆它。

要理解这个池子的作用，先看两个经典写法：

String a = "abc"; String b = "abc"; String c = new String("abc"); System.out.println(a == b); // true System.out.println(a == c); // false

第一行代码执行时，JVM会在常量池中查找是否存在内容为"abc"的对象。没有，于是创建一个并放入池中；有，则直接复用。所以a和b指向的是同一个对象，用==比较返回true。

第三行代码则不同。关键字new明确要求创建新对象，无论常量池里有没有这个字符串，它都会在堆上再new一个。所以c是独立的另一个对象，a == c当然返回false。

这就是那八道经典面试题的第二个版本：String s = new String("abc")创建了几个对象。答案是：如果常量池中原本没有"abc"，创建两个——常量池一个、堆上一个。如果池中已有，只创建一个——堆上那个。注意，这题默认不讨论字符串拼接和intern的情况。

字符串的intern()方法可以把一个字符串对象的内容尝试放入常量池。如果池中已有相同内容的字符串，返回池中对象；如果没有，JDK 7之后的实现是把这个字符串的引用复制到池中，返回这个引用。我对intern的使用一贯保持谨慎，因为它在JDK 7之后虽然不复制字符串内容，但字符串本身仍然无法被GC回收，滥用intern会造成严重的堆内存膨胀。线上有一台老服务器就是因为某个同事在循环里大量调用String.valueOf(...).intern()，把堆直接撑爆了，排查了很久才找到根因。

2. 常用API实操细节：每天都会用但容易踩坑的方法

2.1 字符串构建与转换：valueOf、format、repeat

字符串构建最直接的是字面量赋值和new，但实际开发中，更多时候是从其他类型转换而来。

String.valueOf是数值转字符串的首选方法。它有多个重载版本，分别处理int、long、float、double、boolean、char、char[]、Object。注意它的一个特性：如果参数是对象且为null，返回字符串"null" —— 这是有意为之的，用起来反而安全，不会抛NullPointerException。而String.valueOf(char[])如果传入null，会直接抛NullPointerException，因为底层调用了String.copyValueOf，没有做null判断。这两个情况的差异，我见过不止一个同事在线上栽过。

除了拼接，字符串格式化也是一个高频需求。String.format是类C语言printf风格的格式化方法：

String message = String.format("订单号：%s，金额：%.2f 元，下单时间：%tF %<tT", orderId, amount, LocalDateTime.now());

%s是字符串，%d是整数，%f是浮点数（可以指定小数位），%tF和%tT是时间格式化。实际项目中我建议尽量少用String.format，它在每次调用时都会创建一个Formatter对象并走一遍完整解析流程，性能比直接拼接差一个数量级。日志量大、调用频繁的地方，用占位符拼接或者引入Slf4J的参数化日志，才是更好的选择。

Java 11引入了String.repeat(int)方法，可以用一行代码实现字符串的重复拼接。比如需要生成一个包含100个"-"的分隔线，直接"-".repeat(100)就行。这个方法在底层做了一次数组分配和拷贝，效率远高于循环拼接。面试官比较新潮的话，可能会问到你有没有用过JDK 11中的新增API，repeat确实是值得提的一个亮点。

2.2 截取、替换、分割：substring、replaceAll、split的使用边界

substring方法的两个版本——substring(int beginIndex)和substring(int beginIndex, int endIndex)，都要注意边界条件。Java的区间约定是左闭右开，即包含beginIndex位置的字符，不包含endIndex位置的字符。这个约定跟List.subList、Arrays.copyOfRange保持一致，是Java体系的统一风格。

截取最典型的坑是StringIndexOutOfBoundsException。beginIndex不能为负，不能大于length，endIndex不能大于length，beginIndex不能大于endIndex。用之前先检查字符串长度是个好习惯，特别是处理外部传入的参数时。

JDK 6及以前版本有一个著名的内存泄漏问题：substring方法返回的新字符串会共享原字符串内部的char数组，只通过调整offset和count来实现截取。这意味着原字符串哪怕有几十MB，截取出几个字符的小字符串，也会一直持有完整的大数组，内存根本释放不掉。JDK 7之后修改了这个实现，改为真正复制一份新数组，问题才彻底解决。如果你维护的老项目还跑在JDK 6上，遇到类似的内存问题，第一反应应该检查substring的调用历史。

replace和replaceAll是两个容易混淆的方法。replace(CharSequence target, CharSequence replacement)是纯字面量替换，把所有匹配target的内容替换为replacement；replaceAll(String regex, String replacement)则把第一个参数当正则表达式处理。从JDK 5开始，replace也支持CharSequence参数了，所以大部分场景用replace就够了，只有当第一个参数确实是正则表达式时才需要replaceAll。

这里有个特别实际的坑：replaceAll的第二个参数中，反斜杠和美元符号有特殊含义。$1、${name}代表正则捕获组引用，\用于转义。如果你的替换文本里包含这些符号且不想被解释，需要对它们进行转义。我处理过一次线上事故，某个功能是把用户留言里的某些敏感词替换成“***”，结果留言里恰好有大段正则相关的文本，直接触发了PatternSyntaxException。后来学乖了，替换文本统一用Matcher.quoteReplacement(replacement)包裹一层，彻底规避这个问题。

split(String regex)是字符串分割的主力方法，但它的行为有一堆细节。第一个陷阱是正则特殊字符。如果要按点号分割，比如"192.168.1.1".split(".")，得到的是一个长度为0的数组——为什么？因为点号在正则里是任意字符的通配符，匹配到了每一个位置，分割结果自然是空的。正确写法是"\."。同样需要转义的还有|、*、+、^、$、?等等。对用户输入作为分割符的情况，我建议直接用Pattern.quote来包裹：

String[] parts = input.split(Pattern.quote(userProvidedSeparator));

第二个陷阱是尾随空字符串会被丢弃。举例子，"a,b,c,".split(",")得到的结果长度为3，而不是4——最后一个逗号后的空串不保留。如果希望保留，需要给split传第二个参数limit，值为负数：

String[] parts = "a,b,c,".split(",", -1); // 长度为4，最后一个元素是空串

limit参数的含义是，结果数组的长度不超过limit，但如果limit是负数，则不做任何限制。这个知识点在解析CSV文件时很常用，CSV的一行末尾可能有多余的逗号，直接split会把空字段丢掉，导致列错位。

2.3 判断与匹配：equals、startsWith、matches的适用场景

判断两个字符串内容是否相等，用equals而不是==。这个规则每个Java程序员都能背出来，但深层原因不是所有人都说得清——equals比较的是两个字符串的内容逐字符是否一致，而==比较的是两个引用是否指向同一个对象。内容相同但分布在堆上不同位置的两个字符串对象，用==比较必然返回false。

equalsIgnoreCase是忽略大小写的版本，适合邮箱地址、用户名这类不区分大小写的业务场景。它内部的实现是逐字符比较时统一转成大写再对比，所以没有额外的对象创建开销。

前缀后缀判断用startsWith和endsWith。这两个方法我用得非常频繁，比如判断文件名后缀、URL路径是否以某个前缀开头、是否包含特定标记。它们是专门为前缀后缀匹配设计的方法，语义清晰，性能也很稳定。

matches(String regex)方法做的是全字符串正则匹配，注意是全匹配而非部分匹配。这意味着正则表达式必须匹配整个输入字符串，才能返回true。这和Pattern.matcher(...).find()的语义不同——find只要找到匹配的子串就会返回true。日常开发中，用String.matches做格式校验比较方便，比如校验手机号、邮箱、身份证号。但它的性能不容乐观，因为每次调用都会重新编译正则表达式。如果校验逻辑在循环里执行，我建议提前把Pattern编译好，用Matcher的matches方法代替：

Pattern phonePattern = Pattern.compile("^1[3-9]\\d{9}$"); for (String phone : phoneList) { boolean valid = phonePattern.matcher(phone).matches(); }

3. 字符串拼接背后的性能账本

3.1 加号拼接和StringBuilder的真实差距

字符串拼接最简单的方式是加号，Java语言层面也允许这样操作。但很多人写过这样的代码：

String result = ""; for (int i = 0; i < 10000; i++) { result = result + i; }

这段代码的性能非常差。每次执行result = result + i时，因为String不可变，都不能复用已有的result对象，必须创建一个新的StringBuilder、把result内容append进去、再把整数append进去、最后toString生成新字符串，然后丢弃旧对象。一万次循环，就是一万次对象创建和数组复制，GC压力巨大。

在JDK 5到JDK 8时代，编译器确实会把加号拼接转换为StringBuilder操作。但关键区别在于，每次循环里的result = result + i都会被编译成独立的new StringBuilder加append流程，StringBuilder对象在每次循环里都会新建和丢弃，循环级别的拼接没法复用同一个StringBuilder对象。所以编译器优化解决的只是把两次拼接合并为一次，并没有解决循环拼接的根本问题。

JDK 9开始情况有变。字符串拼接引入了invokedynamic机制，通过StringConcatFactory这个引导方法在运行时决定具体的拼接策略。编译器不再把加号拼接直接翻译成StringBuilder操作，而是生成一个动态调用点，JVM运行时会选择最合适的拼接策略——通常是直接创建字节数组一次性拷贝完成。这比原来的StringBuilder流程效率更高。但即便如此，在循环里用加号拼接依然是反模式，因为循环体里每执行一次拼接，仍然要重新分配一次目标数组。

正确的循环拼接姿势是显式使用StringBuilder：

StringBuilder sb = new StringBuilder(); for (int i = 0; i < 10000; i++) { sb.append(i); } String result = sb.toString();

3.2 StringBuilder的扩容机制与容量预分配

StringBuilder内部维护一个字节数组（Java 9之后是byte[]，之前是char[]）来存放拼接的内容。默认初始容量是16，当append的内容超过当前容量时，会触发扩容。

扩容的算法很简单：新容量等于旧容量的两倍加二。这个两倍加二的设计有点讲究——左移一位是乘以2，加2是为了留一点余量，避免恰好扩容到刚好够用。计算完成之后，如果新容量仍然小于所需的最小容量，就直接用最小容量。这里的最小容量是当前已有内容长度加新追加内容长度，也就是下次扩容后至少要能装下全部内容。

如果内容是确定量级，我建议提前指定容量。StringBuilder和StringBuffer都有带初始容量的构造方法。比如预计要拼接1000条数据，每条几十个字符，直接new StringBuilder(50000)能省去多次扩容的数组复制开销。扩容本质上就是创建一个更大的新数组，然后把旧数组的元素整体拷贝过去——这个拷贝操作如果频繁触发，性能损耗非常明显。

还有一个细节需要提醒：append方法返回的是this，支持链式调用。这种链式写法规避了中间变量，可读性也更胜一筹。很多人写代码时习惯每行一个append，其实可以写成：

StringBuilder sb = new StringBuilder(64) .append("{\"id\":").append(id) .append(",\"name\":\"").append(name) .append("\"}");

StringBuffer是StringBuilder的线程安全版本，所有公开方法都加了synchronized关键字。但日常开发中，字符串拼接几乎都发生在局部变量场景，线程安全根本无从谈起，强行用StringBuffer只是在白白支付锁的开销。只有在少数真正需要跨线程共享拼接对象的情况下（比如多个线程往同一个缓冲区追加日志），才应该考虑StringBuffer或者更优秀的替代方案。

4. equals与hashCode：面试高频的底层逻辑

4.1 equals重写的标准姿势

String重写了Object的equals方法，实现了逐字符内容比较的逻辑。这段逻辑值得深入理解，它是很多面试题的基础，也是日常开发中重写equals时的参照模板。

String.equals的实现大致是这样的：首先用==做一次引用比较，如果两个引用指向同一个对象，直接返回true，这是短路优化；然后判断对方是否为String类型，不是就直接返回false；最后逐字符比较字节数组。在JDK 9的Compact Strings实现下，如果两个字符串的编码标志位不同，会先把某个转换成统一的编码再比较，过程略微复杂，但对外表现仍然是逐字符内容比较。

这里引出一个关键原则：重写equals方法时，必须先判断类型。Object.equals的通用约定包括自反性、对称性、传递性、一致性，以及“非null对象的equals比较永远不会返回null结果”这一条。很多人写equals时忘了null判断，或者没有先比较类型就直接强转，极容易造成意外的ClassCastException。

一个标准的equals重写模板：

@Override public boolean equals(Object o) { // 引用相等直接返回true if (this == o) return true; // 类型不匹配或null返回false if (o == null || getClass() != o.getClass()) return false; User user = (User) o; // 逐个字段比较，引用类型用Objects.equals避免null判断 return Objects.equals(name, user.name) && age == user.age; }

注意一个细节：用getClass() != o.getClass()还是用o instanceof User判断，各有讲究。getClass比较严格要求类型完全一致，子类对象和父类对象互不相等；instanceof则比较宽松，子类对象也能匹配。如果实体类没有继承体系，两者效果一致。但从对称性角度考虑，如果父类用instanceof，子类也重写了equals且同样用instanceof，就容易出现“对称性破坏”的问题。简单场景下，推荐getClass()判断。

4.2 hashCode为什么选31作为乘数

String的hashCode算法是所有Java开发者都接触过的经典：

int hash = 0; for (byte b : value) { hash = 31 * hash + b; }

也就是对字符串的每个字符执行hash = 31 * hash + charAt(i)，最终得到这个字符串的哈希值。这个算法整个计算过程中只有一个常量，那就是31。为什么偏偏是31？

我从网上看过很多分析，综合下来主要有三点。第一，31是奇素数，作为乘法因子能减少哈希碰撞。第二，31可以用移位加减法高效计算：31 * i == (i << 5) - i，在JVM中这个操作比普通乘法快很多。实际上JIT编译器会自动识别31乘法的模式并优化成移位操作。第三，31的乘数在哈希的离散分布上表现不错，很多经典的哈希算法都验证了它对字符串分布有较好的均匀性。

hashCode和equals的搭配有一条铁律：两个对象相等，哈希值必须相等；哈希值相等，两个对象不一定相等。这对应HashMap的查找逻辑——先根据哈希值定位桶，再在桶内用equals寻找目标。所以重写equals必须同时重写hashCode，否则把对象放到HashSet或HashMap的key中时，equals返回true的对象可能被分到不同的桶，直接导致数据错乱。这条规则在面试中必被考察，在实际开发中也是Bug高发区。

4.3 intern的实战陷阱

String.intern()这个方法在面试中经常出现，实际生产环境中也偶有用到。它的作用是：如果常量池中已经有与当前字符串内容相等的字符串，返回常量池中的引用；如果没有，把当前字符串的引用加入常量池并返回这个引用。

JDK 6及以前的intern实现是把字符串内容复制一份到永久代，永久代空间小，大量使用intern很容易抛出OutOfMemoryError: PermGen space。JDK 7之后，永久代移除，常量池挪到堆里，intern的语义也调整为直接在常量池中保存字符串引用，不再复制内容。这解决了内存爆掉的问题，但引入了新的问题——被intern的字符串对象和它的引用一起被常量池强引用，导致GC无法回收。

实际开发中有一个可以利用的场景：对大量内容相同的字符串去重。比如某些场景下系统会频繁创建内容完全一样的字符串对象，通过intern可以让它们复用同一个对象，节省内存。但我的经验是，只在对去重收益有精确评估、且字符串内容集合规模可控的前提下使用。如果字符串的内容千变万化，intern不仅达不到省内存的效果，反而会让常量池里的对象越积越多，最终成为内存泄漏。

5. 编码、字节与正则：字符串的高阶必修课

5.1 字符编码导致乱码的根因与解决

乱码问题几乎是所有Java后端开发者都会遇到的噩梦，它的根源在于字符编码不一致。Java内部字符串统一使用Unicode字符集，但JVM在读取外部数据、网络传输、文件写入时，默认使用平台字符集。当数据的编码方式与JVM解码时使用的编码方式不匹配，就有可能出现乱码。

最常见的一个场景：项目里用new String(bytes)把字节数组转成字符串，但没有指定字符集。JVM会使用默认字符集（通常是操作系统的字符集），如果你的Linux服务器默认是UTF-8，本地Windows是GBK，同一套代码在不同环境里行为就不一致。正确的做法是任何时候都明确指定字符集：

String text = new String(bytes, StandardCharsets.UTF_8); byte[] bytes = text.getBytes(StandardCharsets.UTF_8);

Java 7之后推荐直接使用StandardCharsets.UTF_8，而不是字符串形式的"UTF-8"，后者还需要捕获UnsupportedEncodingException。Java 10之后还有一个更省事的API——String新加了带Charset参数的构造方法重载，但核心思想不变：永远显式指定字符集。

乱码问题还有一些冷门但常见的坑。比如String.getBytes()不带参数时，如果环境默认编码不是UTF-8，就会把字符串按GBK编码成字节数组，再送到用UTF-8解码的地方，立即出现乱码。再比如数据库连接串里如果没指定characterEncoding，MySQL驱动会使用服务器的默认编码，与Java应用的编码不一致，中文写入后读出来就花了。HTTP请求响应头里的Content-Type没有明确charset，浏览器和服务器之间也会出现编解码不一致。

排查乱码问题的通用思路：确认数据的源头编码是什么、传输过程中编码是否有转换、目标端的解码编码是否正确。用十六进制查看字节是最直接的判断方式——一个UTF-8编码的中文字符通常是三个字节，GBK是两个字节，中文标点与英文字符的区别也很明显。如果看到字节序列中混着大量的0xEF 0xBF 0xBD，这表示已经出现了U+FFFD替换字符，也就是数据里的非法编码序列被替换掉了，这种情况更麻烦，说明原始字节已经部分丢失。

5.2 正则表达式在字符串操作中的应用与转义坑

正则表达式是字符串处理的绝对利器。Java里对正则的支持封装在java.util.regex包中，核心是Pattern、Matcher两个类。Pattern负责编译正则表达式，Matcher负责在具体字符串上执行匹配。

很多初学者习惯直接用String.matches、String.replaceAll、String.split这些便捷方法，它们内部确实都会创建Pattern对象，但问题是每次调用都重新编译一次正则。正则在第一次编译后可以通过Pattern对象缓存起来，避免重复编译带来的开销。性能敏感的场景，尤其循环调用时，一定要把Pattern提到循环外面。

我自己维护过一个规则引擎，里面运行着上百条正则校验规则，最初版本就是直接在每个请求里调用matches，一压测就发现CPU时间大部分都耗在正则编译上。后来加了Pattern缓存，性能提升非常明显，QPS直接翻了几倍。正则表达式的编译开销在短小正则场景下不明显，但复杂正则的编译时间可能达到毫秒级，加上调用频繁，一下就暴露了。

正则里还有一大类经典问题——转义地狱。正则本身有大量元字符，Java字符串中反斜杠又需要用另一个反斜杠来表示，于是很多正则表达式在Java代码里看起来像天书。比如匹配一个数字的表达式"\d+"，匹配一个反斜杠需要"\\"，匹配一个点号需要"\."。这个双重转义问题让正则的可读性雪上加霜。

我的建议是，对稍复杂的正则，写成Pattern.compile时用注释或常量命名解释其含义，必要时拆分成小的子正则分别验证。比如：

// 匹配IPv4地址 private static final Pattern IPV4_PATTERN = Pattern.compile("^((25[0-5]|2[0-4]\\d|[01]?\\d\\d?)\\.){3}(25[0-5]|2[0-4]\\d|[01]?\\d\\d?)$");

如果正则的匹配逻辑太复杂，还可以考虑用多个简单正则组合代替，可维护性更好。正则表达式的回溯陷阱也需要提防——某些带嵌套量词的模式（比如(a+)+）在匹配长字符串时可能触发灾难性回溯，导致CPU飙升。这在实际的线上问题是真实存在的，处理用户输入的正则表达式时尤其要小心，必要时用Re2J这样的线性时间正则库替换JDK自带实现。

6. 高频面试题与避坑指南

6.1 高频面试题：从String构造到输出

把面试中最常碰到的字符串题目集中整理成清单，逐个击破，比漫无目的地刷题高效得多。

第一题：String、StringBuilder、StringBuffer的区别。标准答法分三点：String是不可变的，每次修改都创建新对象；StringBuilder是可变的字符串构建类，效率高但线程不安全；StringBuffer在StringBuilder基础上加锁，线程安全但性能稍差。最佳实践是局部变量拼接用StringBuilder，全局共享且需要线程安全时用StringBuffer或考虑其他方案。

第二题：String s = new String("abc")创建了几个对象。前面已经讲过，分两种情况：常量池没有"abc"时创建两个，有则创建一个。这个问题的变形还会加上s.intern()，需要回答清楚intern返回的是池中对象。

第三题：如何反转字符串。最直接的是StringBuilder的reverse方法：new StringBuilder(str).reverse().toString()。如果面试官要求手写实现，可以用双指针交换字符数组。注意reverse同样满足不了所有要求，比如忽略Unicode代理对会导致部分emoji字符反转后乱码，但面试阶段通常不考虑这个细节。

第四题：如何统计字符串中每个字符出现的次数。经典解法是用HashMap<Character, Integer>，Java 8之后可以用merge方法一行搞定：

Map<Character, Integer> count = new HashMap<>(); for (char c : str.toCharArray()) { count.merge(c, 1, Integer::sum); }

merge的第三个参数是重映射函数，表示当key已存在时，把旧值和新值合并的结果作为新值写入。这里有加分项：如果不考虑Unicode补充平面，char遍历没问题；如果字符串可能包含emoji等需要两个char表示的内容，应该用codePointAt逐码点遍历。

第五题：equals和hashCode的关系。必须重写equals时重写hashCode，否则HashMap、HashSet等集合会出现逻辑错误。要能解释为什么——哈希定位依赖hashCode，equals相等但hashCode不等会导致相同对象被分到不同桶。

6.2 线上字符串问题的排查思路

字符串相关的线上故障，最常见的几类我都遇到过，整理成速查表供参考：

除了表格里的常见场景，还有一个容易被忽视的点：字符串对象作为业务数据的载体，在排查OOM时经常扮演隐藏角色。一张导出报表，在内存里拼了几百万行字符串，还没开始写文件堆就满了。我处理过的问题是某个定时任务从数据库捞出全量数据，在内存中循环字符串拼接生成CSV，三千万行数据让堆空间直接炸掉。最终方案是改成流式处理，每攒够一万行就写一次文件，内存占用从几个GB降到几十MB。

字符串面向上线的问题排查，核心思路永远是：先确认数据流向中每一步的编码和存储方式，再用最小化复现的方式定位具体是哪一段操作引发的异常。字符串本身不会出问题，出问题的总是调用它的方式和环境。

我在实际工作中对字符串操作有一个习惯：凡是涉及编码转换、正则匹配、大量拼接的场景，一律写单元测试覆盖边界条件——空串、null、特殊字符、超长字符串。这些边界情况最容易暴露问题，也最难在代码评审中被人眼发现。字符串看似简单，用好了是利器，用不好就是线上事故的温床。最后再分享一个小技巧：如果你不确定某个字符串方法的行为边界，最快的验证方式是在本地写个main方法跑一遍，看结果打印出来是什么，比翻文档和猜快得多。