textarea的wrap属性仅控制渲染折行，不影响提交换行符；用户按enter产生的\n或\r\n才是唯一可信来源，现代浏览器基本忽略wrap="hard"，后端须统一归一化处理。
textarea的wrap属性根本不管用
别指望 wrap="hard" 或 wrap="soft" 控制提交内容里的换行符——它只影响浏览器渲染时是否自动折行显示，对用户按 Enter 输入的 \n 或 \r\n 没有增删改作用。现代 Chrome/Firefox 已基本忽略 wrap="hard" 的换行注入逻辑；Safari 行为不一致；移动端软键盘的 Enter 键是否换行，也和 wrap 无关。
常见错误现象：
- 设了
wrap="hard"，但后端收到的值里多了莫名其妙的\r\n（其实是自动折行点被强行插入的） - 设了
wrap="soft"，文本框里看着是折行的，但提交后服务端拿到的却是单行长字符串（因为没用户按 Enter） - 没设
cols，wrap="hard"直接被浏览器静默降级为soft
用户手动换行才是唯一可信的换行源
用户在 textarea 中按 Enter 键，才会真实产生换行符：\r\n（Windows）、\n（macOS/Linux）。这个行为与 CSS、wrap、cols 全部无关，是原生输入行为。
前端可做最小干预：
- 用
value.replace(/\r\n|\r/g, '\n')统一为\n，方便后续处理 - 监听
input事件（不是keydown），确保粘贴进来的换行也被捕获 - 避免用
value.length做“行数”校验——它统计的是 Unicode 码点数，\r\n算 2 个字符，\n算 1 个；真要算行数，用value.match(/\r\n|\r|\n/g)?.length || 0
后端必须兼容所有换行符变体
不能假设用户一定发 \r\n。不同系统+浏览器组合可能提交 \r\n、\r 或 \n，且 URL 编码后变成 %0D%0A 或 %0A。框架如 PHP 的 $_POST 会自动解码，但裸读 php://input 或 Node.js 的 req.on('data') 需手动 urldecode()。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
安全处理建议：
- PHP：先
str_replace(["\r\n", "\r"], "\n", $raw)，再htmlspecialchars(..., ENT_QUOTES, 'UTF-8')，最后nl2br() - 切分段落别用
split('\r\n')，改用正则/\r\n|\r|\n/g或语言内置安全方法（如 Python 的str.splitlines()） - 数据库存储前不要
trim()掉末尾换行——用户可能真想留空行
placeholder 里想换行？别试了
textarea 的 placeholder 属性规范禁止换行：所有空白符（包括 \n）都会被压缩成单个空格。CSS 的 white-space: pre-wrap 对 ::placeholder 伪元素完全无效，Chrome/Firefox/Safari 全都不认。
可行方案只有两个：
- 把说明文字挪到
textarea外部，用<label></label>或灰色小号<p></p>标签 - 用绝对定位的
<div> 模拟 placeholder，同步 <code>input和focus事件控制显隐，严格匹配字体、行高、颜色（注意：需监听resize和滚动重定位）千万别用
contenteditable替代textarea——表单提交不自动同步、iOS 中文输入法光标错乱、失去原生rows/cols行为，坑比功能多。
