文本转义
引号、换行、尖括号——拼字符串时最容易出事的地方，先在这里转好。
SQL 转义只是把单引号翻倍，不能替代参数化查询。拼接 SQL 始终有注入风险，这里只用于生成调试用的字面量。
什么时候用
- 手写 JSON 请求体，只要把一段用户输入塞进某个字符串值里：JSON 模式返回的正是引号内部那份转义结果，反斜杠、换行、制表符都已经处理，直接替换占位符即可。
- 日志或接口字段里出现 " 这种字样，想弄清它被转义了几层：把片段贴进 HTML 模式还原一次，如果还剩 " 就说明至少转了两层。
什么时候不用
- 准备把不可信输入拼进 SQL 语句：SQL 模式只是把单引号翻倍，MySQL 默认仍把反斜杠当转义符，数值位置、ORDER BY 列名、LIKE 通配符更不在保护范围内，能改代码就换成参数化查询（? 或 $1）。
- 要把用户提交的 HTML（评论、富文本）清洗后插进页面：这里只替换 & < > " ' 五个字符，on* 事件属性、javascript: 伪协议、无引号的属性全部照原样通过，XSS 过滤请用 DOMPurify 这类白名单清洗器。
转义与还原都在浏览器本地完成，输入不上传、不写日志。限制：JSON 模式只处理单个字符串值、不校验整段文档；SQL 模式仅翻倍单引号，在 MySQL 反斜杠模式与数值位置不构成防护，不能替代参数化查询；HTML 模式只覆盖 5 个字符。
常见问题
SQL 转义能防 SQL 注入吗？
单靠它不行。SQL 模式只是把单引号变成两个，这是标准 SQL 里引用字面量的写法；但 MySQL 默认开启反斜杠转义，\' 依然能逃出去，GBK 这类宽字节编码历史上还有专门的绕过手法；数值参数、ORDER BY 的列名、LIKE 里的 % 和 _ 更不是加引号能解决的。它只适合临时手工查一下数据、让字符串别报语法错。应用代码里请用参数化查询或预编译语句，转义只能当兜底，不能当防线。
为什么 JSON 转义结果没有首尾的双引号？
因为工具给的是字符串内部的内容，方便你直接放进已有的 "..." 之间。需要完整 JSON 字面量时自己补外层双引号。还原时它把整串当一个 JSON 字符串解析，串里出现未转义的引号会直接报错，而不是返回半截结果，所以别拿它去猜一个残缺转义串的含义。另外要把结果嵌进 HTML 的 <script> 里，还得额外处理 </script> 与 U+2028、U+2029，否则脚本会提前闭合或语法报错。
连续转义两次，& 变成了 &amp;，是 bug 吗？
不是。转义本来就不幂等：第一次 & 变成 &，第二次把其中的 & 又转一遍，就成了 &amp;。这正是「页面上直接显示 & 字样」的典型原因——数据被转义了两次，却只还原了一次。正确做法是只在写入目标上下文的那一刻转义一次；拿到别人转义过的字段时，先确认它到底转了几层，再一次还原到位，不要看到 & 就条件反射地点一次。