JS字符串换行符：Windows环境下是否统一识别为LF？

你猜的没错——在JavaScript中，不管运行环境是Windows还是类Unix系统，字符串里的换行符都会被统一处理为LF（\n），哪怕你的源文件在Windows里是用CR+LF（\r\n）存储的。

为什么会这样？ #

这是ECMAScript标准明确规定的行为：当JS引擎解析字符串字面量（包括你用的模板字符串）时，会自动把源文件中的CR+LF、CR等换行序列都转换为单个的LF字符。目的是让字符串处理逻辑在所有平台上保持一致，避免跨平台开发时的换行符混乱问题。

结合你的代码分析 #

看你写的模板字符串：

var string = `
foo
bar
`;

虽然这个字符串在Windows的本地文件里存储时，每一行结尾是\r\n，但JS解析后，内部的字符串内容其实是："\nfoo\nbar\n"——完全没有\r字符。

这就是为什么你用/^(\s*\r\n){2,}/gm这个正则替换会无效：字符串里根本不存在\r\n的序列，自然匹配不到任何内容。而你注释掉的/^(\s*\n){2,}/gm能正常工作，就是因为它匹配的是JS内部实际存在的LF换行。

解决方案 #

1. 处理JS内部字符串（比如字面量、模板字符串）：直接使用LF相关的正则即可，也就是你已经写好的注释代码：

string = string.replace(/^(\s*\n){2,}/gm, '\n');

2. 处理外部读取的含CR+LF的字符串：如果你的字符串是从外部来源获取的（比如通过File API读取本地文本文件、后端接口返回的CR+LF格式内容），可以先统一转换为LF，再做后续处理：

// 先统一把CR+LF转换成LF
string = string.replace(/\r\n/g, '\n');
// 再处理空行
string = string.replace(/^(\s*\n){2,}/gm, '\n');

验证方法 #

你可以在代码里加一行日志，打印字符串的JSON格式，就能直观看到内部的换行符：

console.log(JSON.stringify(string));

运行后你会看到输出是"\nfoo\nbar\n"，完全没有\r，这就实锤了JS内部统一用LF的结论。

内容的提问来源于stack exchange，提问作者john c. j.