wrap属性不可靠：wrap="soft"仅视觉折行且不插入换行符，wrap="hard"需配合cols才可能在视觉断点插入\r\n，但属渲染副作用；应通过JS清理+服务端normalize统一换行符。
wrap 属性不能可靠控制提交时的换行行为——它只在部分浏览器中“尝试”插入换行符，且插入位置、是否生效全凭运气。你看到的折行 ≠ 提交的换行符，用户没按 Enter 的地方也可能被塞进 \r\n，而用户真按了 Enter 的地方，又可能被吃掉。别把它当开关用。
wrap="soft" 和 wrap="hard" 到底干了什么
wrap="soft" 是默认值，它只影响显示层：浏览器在视觉上按 cols 或 CSS 宽度自动折行，但提交时完全不插入额外换行符，只保留用户手动按 Enter 输入的换行（可能是 \r\n、\n 或混合）。wrap="hard" 会强制在每行视觉末尾插入 \r\n，但前提是必须同时设置 cols 属性，否则多数浏览器直接忽略该设置。
-
wrap="soft"下，超长行不会被截断，也不会插\r\n，但显示仍会折行（这是 CSS 行为，和wrap无关） -
wrap="hard"插入的\r\n是渲染副作用，不是用户意图——比如在单词中间因宽度限制被硬切，就会多出一个非预期换行 - 旧版 IE 对两者支持混乱；移动端（尤其 iOS/Android 软键盘）对
wrap基本无响应
为什么 wrap="hard" 提交了不该有的 \r\n
浏览器在 wrap="hard" 下，只要文本视觉上到达 cols 边界（例如第 40 列末尾），就会自动在那个位置插入 \r\n，哪怕光标根本没停过、用户也没按 Enter。这些 \r\n 是渲染副作用，常见于长段落自动折行后多出的空行或断词处。
- 必须显式设置
cols，否则wrap="hard"大概率失效 - 用户编辑、粘贴、光标移动后，浏览器可能补加或删减这些自动换行符
- 服务端若按
\r\n切分段落，会把“自动折行”误判为用户主动分段
真正该用的方案：JS 清理 + 后端 normalize
想让提交内容只保留用户真实意图的换行，就得绕过 wrap，自己动手清理。提交前统一换行符格式，并在服务端做归一化处理。
- 提交前用 JavaScript 清理：
textarea.value.replace(/[\r\n]+/g, '\n').replace(/\n(?=\s*$)/g, '')—— 先统一成\n，再删结尾空白行 - 不要在
input或keydown中实时修改value，会破坏中文输入法（IME）状态和光标位置 - 服务端接收后第一件事：用正则
/[\r\n]+/g切分，存储时统一转为\n，避免数据库或日志解析出错 - 展示后端返回的文本时，用
white-space: pre-wrap，不是靠wrap="hard"—— 后者只作用于自身，对或无效最常被忽略的一点：你永远不能在服务端代码里写
if (str.contains('\r\n'))就认为这是用户换行——因为\r\n可能是wrap="hard"注入的，也可能是 macOS 用户发来的\n，还可能是 Word 粘贴进来的\r。换行符从来就不是可靠的语义标记，得靠上下文和清洗逻辑来还原用户意图。
