textarea提交时换行符取决于用户操作系统：Windows通常为 ，macOS/Linux多为 ；后端应使用/[ ]+/正则分割而非假设单一换行符，避免split(' ')导致空行等解析错误。
textarea 中的换行符在不同系统里到底存成什么
textarea 提交时的换行符不是统一的
，而是取决于用户操作系统和浏览器行为：Windows 用户按 Enter 通常生成
，macOS 和 Linux 大多是
。这个差异会在后端解析时引发问题——比如用 split('
') 切分 Windows 提交的内容，会把
当作一个字符切出空行。
实操建议：
- 前端若需标准化，可用
value.replace(/ /g, ' ').replace(/ /g, ' ')统一为 - 后端接收时别假设换行符类型，优先用正则
/[ ]+/分割，或直接用语言内置的splitlines()（Python）、Lines()（Go）等安全方法 - 数据库存储前不建议盲目 strip
form 提交时 textarea 换行会不会被 encode 或截断
不会被截断，但会被 URL 编码：换行符在 application/x-www-form-urlencoded（默认 POST）中会被转成 %0D%0A（对应
）或 %0A（对应
）。服务端框架（如 Express、Django）一般自动 decode 并还原，但裸写 Node.js req.on('data') 或 PHP $_POST 以外方式读取原始 body 时，得自己处理百分号解码。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 用
fetch发送FormData时，textarea 值里的换行正常保留；但若手动拼 query string（如key=value1%0Avalue2），没做encodeURIComponent(textarea.value)就会丢换行 - PHP 中
$_POST['field']已解码，但file_get_contents('php://input')拿到的是原始编码值，需调用urldecode() - Nginx 默认不限制换行，但若配了
underscores_in_headers on之类非相关指令，可能干扰某些特殊 header 解析（与换行无关，但常被误关联）
用 JavaScript 获取 textarea 实时换行数或校验长度含回车
textarea 的 .value.length 直接返回 Unicode 码点数量，
算 2 个字符，
算 1 个——这和用户“视觉上按了多少次回车”不一致，也影响字数限制逻辑。
实操建议：
- 统计“用户感知的换行次数”：用
value.match(/ | | /g)?.length || 0 - 限制总字符数（含换行）就直接用
.length；若想按“显示行数”限高，应结合rows属性和wrap="off"控制是否软换行 - 监听
input事件比keydown更可靠——后者捕获不到粘贴进来的换行，且 Ctrl+Enter 等组合键行为不统一
后端收到的换行在 JSON API 和表单提交中表现一样吗
不一样。表单提交（application/x-www-form-urlencoded 或 multipart/form-data）中换行由浏览器编码，后端框架多数能还原；但若前端用 JSON.stringify({ desc: textarea.value }) 发送，则换行符原样进入 JSON 字符串，JSON 标准允许
、
、
，但必须是合法转义（即 JS 字符串里写成 "line1\nline2"，最终 JSON 是 "line1
line2"）。
容易踩的坑：
- Vue/React 中直接把
textarea.value插入 JSON 对象，没问题；但若先用.replace(/ /g, '<br>')
再塞进去，就破坏了原始换行结构 - Node.js 的
JSON.parse()能正确处理 - gRPC-Web 或其他二进制协议传输时，换行无特殊处理，和普通字符一样，但要注意 protobuf 的
string类型对 UTF-8 的要求
offsetHeight / lineHeight 算显示行数，后端用 count("
") 算逻辑行数，而用户复制粘贴进来的内容可能自带混合换行符——这事没法靠一次 replace 解决，得在关键路径做归一化。 
