htmlspecialchars()没生效是因为调用时机或参数错误：默认不转义单引号，需用ent_quotes；禁止入库前转义；json数据须在输出前转义；v-html/dangerouslysetinnerhtml需配合dompurify；换行需nl2br()或css处理；转义仅限html输出环节。
PHP中htmlspecialchars()为什么没生效？
常见情况是表单提交后，、<code>& 等字符仍原样显示或引发XSS，不是函数没用，而是调用时机或参数错了。默认只转义双引号和<code>>&"，但若表单值来自数据库或JSON接口，可能含'（单引号），而htmlspecialchars()默认不处理它。
- 必须显式传
ENT_QUOTES：htmlspecialchars($str, ENT_QUOTES, 'UTF-8') - 千万别在入库前用——这会让数据库存的是转义后的字符串，后续再输出时又转一次，变成
< - 如果前端用
fetch提交JSON数据，PHP收到的是原始字符串，需在echo前统一转义，而非在$_POST赋值时就处理
Vue/React里v-model或value绑定后HTML被解析
框架默认把插值{{ content }}或{content}当纯文本渲染，但若你手动拼接v-html或dangerouslySetInnerHTML，且内容来自表单输入，就等于开了XSS入口。这不是转义失效，而是你主动绕过了框架保护。
- 永远避免对用户输入直接用
v-html；改用v-text或{{ }}（Vue）/{content}（React） - 如果必须渲染富文本，先用DOMPurify清洗：
DOMPurify.sanitize(dirtyHtml)，别自己写正则过滤 - 注意：Vue 3的
v-html不自动转义，React的dangerouslySetInnerHTML更不转义——名字已经警告你了
表单提交时URL编码导致后端收到乱码
浏览器对application/x-www-form-urlencoded格式自动做URL编码，比如空格变+、中文变%E4%BD%A0。后端PHP默认能正确解码，但Node.js的express需配urlencoded中间件，否则req.body为空或乱码。
- Express必须启用：
app.use(express.urlencoded({ extended: true })) - 若用
fetch且Content-Type设为text/plain，后端收不到req.body——表单数据不会自动解析 - 测试时用
console.log(encodeURIComponent('你好'))确认前端编码是否正常，再比对req.body实际值
textarea里换行符在HTML中不显示
textarea提交的换行是\n，但HTML渲染时忽略所有空白符，\n不会变成
。这不是转义问题，是HTML渲染规则本身。
- 后端输出时用
nl2br()（PHP）或str_replace("\n", "<br>", $str)（注意只替换\n，Windows换行\r\n要先str_replace("\r\n", "\n", $str)） - 前端展示时，CSS加
white-space: pre-line也可保留换行，但无法防XSS——仍需先转义再设样式 - 别在
textarea的value属性里硬塞<br>，浏览器会把它当普通字符显示出来
最常被忽略的点：转义动作必须严格限定在「输出到HTML」这一环节，而不是在存储、传输或JS变量赋值时提前转。一旦搞错层级，要么双重转义，要么漏转——两者都会让页面表现异常。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
