导语
在HTML中遇到一些类似“”，“”等符号与标签混合的case时，通常做法是用HTMLEntity对符号做一层转义编码，但这在某些场景下会遇到一些bug，本文介绍一种针对此类bug的另类处理姿势。
从一个bug说起某天产品反馈了一个问题，业务一页面的富文本展示有问题，管理后台输入的是abc，但最终页面只展示出a。定位发现富文本渲染存在一个问题逻辑，它针对管理后台输入的HTMLEntity字符做了还原，在输入一些类似HTML标签的字符时，浏览器在展示时将输入识别成HTML标签，结果这部分字符便凭空消失。
此处的富文本渲染流程：
HTML输入--Entitydecode--dangerouslySetInnerHTML--DOM--最终UI
当HTML输入类似这样的格式：palt;blt;c/p，Decode以后它变成了pabc/p，导致后面的bc被识别成了HTML的Tag，只留下a在节点中：
解决这个问题，最直接的办法自然是拿掉Entitydecode这一步骤，但实际操作时陷入一尴尬境地：这段逻辑属于积淀多年的历史代码，被众多地方引用，改动影响范围过大，且带来很大的测试工作量，不敢轻举妄动。
从稳妥的角度出发，既然难以干掉，在有机会赶上大规模测试前，那么是否可以先简单上一个对冲的机制？以此抵消Entitydecode的作用，产生预期内的UI效果；并把改动控制在问题模块内，不影响到其他引用此渲染逻辑的模块，从而让测试工作量变得可控。
修改后的富文本渲染流程类似：
HTML输入----Entitydecode--dangerouslySetInnerHTML--DOM--最终UI
实验表明，确实可以！
理论学习关于这个逻辑的实现，直接针对会出问题的场景做个替换，是最朴实简单粗暴的想法。但这本身治标不治本，且还带着引发新的问题的担忧。我们能否从本质角度，一次处理完所有可能的case？
HTML存在的意义，并非它各种奇奇怪怪的语法，更核心的点在于描述要让浏览器构造一个什么样的DOM树，所以我们的