HTML验证不改变字符串，但浏览器解析会修改HTML结构，导致正则在原始字符串上失效；应明确匹配对象是原始HTML还是DOM，避免用正则解析嵌套或动态HTML。
这里有个常见的理解偏差：HTML验证本身并不会“导致”正则匹配失败。真正的问题在于，验证过程（比如浏览器的解析、DOM构建、实体解码）会悄无声息地改变原始字符串的结构，让你精心编写的正则，在面对那个“已经变了模样”的字符串时，突然失灵。所以，问题的核心就变成了：你究竟在匹配什么？是原始的HTML字符串，还是渲染后的DOM？
正则匹配的是原始 HTML 字符串，不是渲染后的 DOM
很多人习惯性地认为，通过document.body.innerHTML或outerHTML拿到的就是“原始输入”。事实并非如此，这已经是浏览器经过解析和规范化处理后的结果了。它会压缩多余的空格、重排属性顺序、为自闭合标签补全斜杠（比如 这类实体直接转换成实际空格……这些细微的改动，足以让基于原始HTML编写的正则表达式失去准头。
- 假设服务器返回的是
hello world
(.*?)
hello world。可一旦你从innerHTML里取值， - 再比如，属性值里如果包含了
<或>（像），在原始字符串里它们是转义后的>，但在DOM中已经被解码还原。这时候，如果你还用title="([^"]*)"这样的模式去匹配，就会因为提前遇到解码后的>符号而错误截断。 - 原始HTML中精心设计的换行和缩进，在
innerHTML的返回值里常常被抹平，那些依赖\n或特定空白符\s+的正则，自然也就失效了。
需要匹配特定标签内容时，别硬套 (.*?)
这个看似万能的“非贪婪匹配”模式，一旦遇到嵌套标签、属性值里包含引号或者HTML实体，就很容易崩溃。举个典型例子： inner
]*>(.*?) .*?会在遇到第一个- 如果只想匹配最外层且确定内部没有同名的子标签，可以考虑使用带回溯检查的复杂模式，例如
<(div)[^>]*>((?:(?!).)*)。但请注意，这通常需要启用dotall标志（在Python中是re.DOTALL，在Ja vaScript中是/s），让点号.也能匹配换行符。 - 当属性值里既可能出现双引号又可能出现单引号时，别简单地用
["']([^"']*)["']。更稳妥的做法是利用引号配对：=(["'])(.*?)\1，这样能确保捕获到完整的、包含另一种引号的内容。 - 抓取
会更安全。使用[\s\S]来匹配“任何字符”，比依赖dotall标志的.适应性更强。
验证阶段已解码，正则却还在匹配转义字符
这里有个细节很容易被忽略。HTML验证本身，比如调用checkValidity()这个方法，并不会改变字符串。但问题在于，验证之后你往往会去获取element.textContent或表单的value，这些值返回的已经是浏览器解码后的纯文本了——而你写的正则，很可能还在傻傻地寻找<、>这类转义字符，当然会一无所获。
立即学习“前端免费学习笔记（深入）”；
- 用户在输入框里键入
avalue确实是ainput.value去读取时，拿到的是已经还原的a/，就永远匹配不到。 - 从
innerHTML提取内容后，如果需要与原始HTML字符串进行比对或操作，可能需要手动将提取出的文本再编码回去，否则像re.sub(r'<', ...)这样的替换操作就可能漏掉那些以实体形式存在的符号。 - 最安全的做法是：始终明确你的数据来源。要匹配原始HTML，就直接用
fetch或XMLHttpRequest去获取原始的响应体字符串；要处理用户最终看到的内容，就用textContent或value，并针对解码后的文本编写匹配规则。
真正该停手的时候：只要涉及嵌套、属性动态、用户输入或验证反馈
正则表达式是个强大的文本处理工具，能快速清洗和提取简单的片段，但它毕竟不是HTML解析器。当你发现自己的正则开始不断增加各种例外分支（比如“如果标签里面还有标签就跳过”、“如果属性值有换行就再多抓几行”），这就发出了一个明确的信号：你已经越过了正则表达式的合理边界。
- 只是要获取某个
id="main"元素的内部HTML？直接用document.getElementById('main').innerHTML，别再用复杂的正则去扫描整个文档字符串了。 - 需要校验用户输入是否包含恶意脚本标签？使用
DOMParser将字符串解析成DOM，然后遍历节点进行检查，这比任何精心设计的正则都更可靠、更省心。 - 如果服务端返回的JSON数据里嵌入了HTML片段（像
{"html": "），正确的流程是先test
"}JSON.parse，再使用DOMParser去处理那个html字段的值，而不是对整个JSON字符串运行HTML正则。
最后，还有一个最容易被忽略的关键点：正则匹配成功，绝不等于语义正确。一个开始标签，可能根本没有对应的闭合标签，或者整个被包裹在注释里，正则表达式无法识别这种深层的语法结构错误——而HTML验证器和浏览器可以。在这种时候，相信专业的解析器，远胜过相信一段脆弱的正则表达式。
