wrap="hard" 会在提交时注入非用户输入的\r\n，因其仅依据cols和字体度量在视觉断点自动插入\r\n，这些换行是渲染层副作用，提交时才生效，且未设cols时多数浏览器退化为soft，中文易语义断裂，移动端完全不响应。
wrap="hard" 为什么会在提交时注入非用户输入的 \r\n
浏览器在 wrap="hard" 下，只看 cols 值和当前字体度量，一旦文本视觉上到达第 cols 列边界（比如第 40 个字符位置），就自动在该处插入 \r\n ——不管光标是否停在那里、用户有没有按 Enter。这些换行符是渲染层副作用，不是 DOM 值的一部分，直到表单提交那一刻才“生效”。
常见错误现象：<textarea wrap="hard"></textarea> 没设 cols，结果 Chrome/Firefox 直接忽略它，退化为 soft；中文场景下，断点可能落在句号后或字中间，导致“你好。\r\n世界”这种语义断裂。
- 必须显式设置
cols，否则wrap="hard"在多数浏览器中不触发 - 粘贴长文本后编辑，浏览器可能补加或删减这些自动换行，行为不可预测
- 移动端完全不响应：iOS 软键盘 Enter 是换行，Android 多数是“发送”，
wrap对此零干预
wrap="soft" 不等于“没换行”，也不等于“安全”
wrap="soft" 是默认值，它只控制显示层是否视觉折行，不影响 textarea.value 的实时内容，也不阻止用户按 Enter 输入真实换行符。但它不归一化、不纠错——你收到的换行符可能是 \r\n（Windows）、\n（macOS/Linux），甚至混合出现。
常见错误现象：设了 wrap="soft"，但 textarea 里文字挤成一长条不折行——通常是因为 CSS 覆盖了默认行为，比如 white-space: nowrap 或容器宽度未约束；也有人误以为它“禁用了换行”，其实只是没插额外的 \r\n。
-
wrap="soft"和white-space: pre-wrap可共存：前者管自动折行逻辑，后者管空格与换行符保留策略 - 它不解决跨平台换行符差异，也不过滤粘贴进来的 Word/邮件内容里的
\r或\r\n混合 - 服务端若只用
.split('\r\n')解析，会漏掉 macOS 用户的真实换行
真正可控的换行清理必须靠 JavaScript
想让提交值只含用户主动按 Enter 输入的换行，就得绕过 wrap，自己动手清洗。不能在 input 或 keydown 中实时改 value，否则会破坏中文输入法（IME）状态和光标位置。
实操建议：
- 监听
submit事件，在e.preventDefault()后处理：textarea.value.replace(/\r\n|\r|\n/g, '\n')，统一转为\n - 若要剔除
wrap="hard"注入的冗余\r\n，可用：.replace(/\r\n(?!\S)/g, '')（删后面没非空白字符的） +.replace(/\r\n(?=\s*$)/g, '')（删结尾空行） - 别用
if (str.contains('\r\n'))判断换行是否存在——这个判断在 2026 年仍不可靠
后端永远不能信任前端传来的换行符格式
即使你前端做了清洗，不同操作系统+浏览器组合仍可能发来不同换行符：\r\n（Windows/Chrome）、\n（macOS Safari）、甚至 \r（极少数旧系统）。这不是 bug，是规范允许的行为。
服务端处理要点：
- 切分段落必须用正则：
text.split(/\r\n|\r|\n/g)，不能只认\r\n - 存储进数据库前统一转为
\n，避免日志解析或 SQL 查询出错 - 展示时用
white-space: pre-wrap，而不是依赖wrap="hard"——后者只对<textarea></textarea>生效，对<div> 或 <code><p></p>无效最常被忽略的一点：你永远无法靠
wrap属性区分“用户按的 Enter”和“浏览器塞的\r\n”——这个边界，它从没划清过。
