表单提交时换行符丢失？textarea值里的
去哪了
HTML 表单本身不“吃掉”换行符，但后续处理环节（尤其是服务端或 JS 字符串操作）常把
当成普通空白忽略。最常见现象是：用户在 textarea 里按了回车，提交后显示成一整段——问题不在表单，而在你没保留或没正确渲染这些换行符。
关键点：textarea 的 .value 是原样包含
的，但一旦用 innerText 显示、或传给某些模板引擎、或被 PHP 的 trim() / strip_tags() 处理，就容易丢。
- 用
textContent或innerHTML+white-space: pre-wrap渲染，别用innerText - 服务端接收后，检查原始 POST 数据是否含
var_dump($_POST['field'])或console.log(req.body.field)），别急着trim() - 如果走 JSON 提交，
JSON.stringify()会保留\n字符串再解析（需前后端约定）
前端显示换行：CSS 比 replace(/
/g, '<br>')
更可靠
很多人第一反应是用 JS 把
替换成 <br>，但这容易 XSS（如果内容未过滤）、破坏语义、且移动端缩放时 <br> 行高难控。
更稳的做法是靠 CSS 控制空白符行为：
立即学习“前端免费学习笔记（深入）”；
- 目标元素加样式：
white-space: pre-wrap（保留换行和空格，自动换行）或white-space: break-spaces（兼容性稍差，但对多空格更友好） - 确保该元素是块级（如
<p></p>、<div>），内联元素（如 <code><span></span>）即使设了也不生效 - 如果必须用
replace，至少做 HTML 转义：text.replace(/ /g, '<br>').replace(/&/g, '&').replace(/, '/g, '>') - 确认是否启用
magic_quotes_gpc（PHP 5.4+ 已移除，但有些兼容层会模拟）：var_dump(get_magic_quotes_gpc()) - 检查框架配置，比如 Laravel 的
TrimStrings中间件、ThinkPHP 的自动过滤，临时关掉测试 - 安全起见，服务端存入数据库前用
nl2br()是下策；应存原始 - Vue 中检查 computed setter 或 watch 是否误处理了字符串（尤其用了
String(value)） - React 中确认 state 更新没经过
value.replace(/s+$/g, '')这类清理逻辑 - 调试技巧：在 input 事件回调里打日志
console.log(e.target.value.length, e.target.value.split(' ').length)，确认浏览器是否真的传出了换行
PHP 接收后换行变空格？检查 magic_quotes_gpc 或自动 trim
老项目里常见：PHP 7.4 以下 + 开启了已废弃的 magic_quotes_gpc，会导致
被转义成 \n；或者框架/中间件默认对所有输入调用 trim()，而 trim() 默认会删掉 ASCII 0–32 的控制字符，包括
（实际只删首尾，但若用户只输一个换行，就真没了）。
Vue/React 中 v-model / value 绑定后换行消失？注意双向绑定劫持
Vue 2 的 v-model 对 textarea 是语法糖，底层仍是 .value，一般不会丢换行；但 Vue 3 的响应式系统或某些自定义指令（如防抖输入、格式化指令）可能在 set 时做了 .toString().trim() 类操作。
React 同理：value 属性受控时，state 必须完全等于用户输入，否则 React 会重置 DOM 值。
）的保全与呈现问题。最容易被绕开的环节，其实是服务端日志里没打印出原始字节——你根本不知道它是不是一开始就被吞了。
