没用且易出 bug；浏览器提交表单时会自动 URL 编码或边界处理，无需 JS 手动转义 HTML 实体。
表单提交前手动转义 & <code>> " ' 有用吗？
基本没用，还容易出 bug。浏览器在表单提交（尤其是 application/x-www-form-urlencoded 或 multipart/form-data）时，会自动对值做 URL 编码或边界处理，不需要、也不该由 JS 手动转义 HTML 实体（比如把 换成 <code>）。手动转义反而可能导致：后端收到双重编码的字符串、富文本内容被破坏、JSON 字段解析失败。
真正要做的，是分清场景：
- 如果目标是「防止 XSS」，防护点在服务端渲染时（比如模板引擎自动转义），不是在表单提交前
- 如果目标是「让数据能安全存进数据库」，靠的是参数化查询，不是前端转义
- 如果目标是「在页面上显示用户输入的内容」，那得在插入 DOM 前用
textContent或框架的自动转义机制，而不是提前改表单 value
后端收到 <script></script> 却执行了？说明没做输出转义
这是典型的输出上下文混淆：前端提交的只是普通字符串 "<script>alert(1)</script>"，它本身不危险；危险的是后端把它拼进 HTML 页面时没做处理。比如 PHP 中直接 echo $_POST['msg']，或者 Node.js 里用 res.send(`...${userInput}...`)。
正确做法取决于你用的模板或框架：
立即学习“前端免费学习笔记（深入）”；
- EJS / Pug：默认
是转义的，要用才不转义（慎用） - React：JSX 插值天然转义，除非显式用
dangerouslySetInnerHTML - Vue：
{{ }}默认转义，v-html才不转义 - 纯 HTML + 后端字符串拼接：必须调用对应语言的转义函数，如 Python 的
html.escape()、Go 的html.EscapeString()
encodeURIComponent() 和 escape() 别混用
escape() 已废弃，不处理 +、/、~ 等字符，且对 Unicode 支持差，绝对不要用。唯一推荐的是 encodeURIComponent() —— 但它只适合构造 URL 查询参数，**不能用于替代 HTML 转义**。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
常见误用：
- 把用户输入传给
innerHTML = encodeURIComponent(val)→ 页面显示一堆%E4%BD%A0%E5%A5%BD，不是转义，是编码 - 用
encodeURIComponent()处理整个表单再发 Ajax → 后端收到的是 URL 编码后的字符串，还得解码一次，多此一举 - 提交 JSON 数据时对字段值单独
encodeURIComponent()→ 破坏 JSON 结构，导致JSON.parse()报错
记住：URL 编码 ≠ HTML 转义。前者为传输安全，后者为渲染安全。
富文本场景下，怎么平衡「显示原样」和「防 XSS」？
用户真要发 <b>加粗</b>，又不能让它执行，就得用白名单过滤，不是简单替换字符。靠正则删掉所有 <script></script> 标签？绕过方式太多（<img src="https://img.php.cn/" alt="HTML表单如何转义特殊字符_HTML表单转义特殊字符流程【操作】">、<svg onload="…"></svg>）。
可行方案只有两个：
- 用成熟库做服务端净化，如 Python 的
bleach、Node.js 的DOMPurify（服务端版）、PHP 的HTMLPurifier - 前端展示时用
iframe sandbox隔离，或限制为 Markdown 输入 + 客户端渲染（如marked配合xss选项）
别自己写“过滤 script 标签”的逻辑。XSS 的攻防不在字符层面，而在解析器行为层面。
最常被忽略的一点：转义必须绑定到具体输出上下文。同一段数据，在 HTML body 里要转义，在 JS 字符串里要加反斜杠，在 CSS 里要换十六进制，在 URL 参数里要 encodeURIComponent——没有“一劳永逸”的转义函数。
