必须在调用 loadhtml() 前用 preg_replace('/[ - - ]/u', '', $html) 清洗 html，保留 ，配合 libxml_use_internal_errors(true) 捕获错误。
DOMDocument::loadHTML() 因 崩溃怎么救
PHP 的 DOMDocument::loadHTML() 遇到 会直接崩溃，不是报错而是 PHP 进程中断，因为 libxml 对 C0 控制字符零容忍。它不会跳过、不修复、不警告， 后所有 HTML 内容被截断，导致 DOM 构建彻底失败。
- 必须在调用
loadHTML()前清洗：用preg_replace('/[ - - ]/u', '', $html)，注意保留 -
strip_tags()和htmlspecialchars()完全无效——它们运行在字符串层面，而 - 若源头是 MySQL，加一层
mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8')可同时处理非法字节和部分乱码实体 - 务必配合
libxml_use_internal_errors(true)，否则崩溃时连错误捕获机会都没有
lxml.etree.parse() 报 UnicodeDecodeError 到底是不是编码问题
Python 的 lxml.etree.parse() 或 fromstring() 报 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xXX，大概率不是编码声明写错，而是原始字节流里混入了 – 等非法控制字符，破坏了 UTF-8 多字节序列边界。
- 别急着改
encoding='gbk'或加errors='ignore'——这会让后续解析更隐蔽出错 - 安全做法：用
response.content（bytes）而非response.text（str），先做二进制清洗：re.sub(b'[ - - ]', b'', raw_bytes)，再 decode - 如果必须用 str 输入，过滤逻辑要覆盖未配对代理项：
re.sub(r'[ud800-udbff](?![udc00-udfff])|(? -
recover=True只修标签结构（如漏闭合），不碰字节解码——Unicode 错误它完全不管
浏览器 Elements 面板里哪些视觉线索暴露非法字符影响
非法字符本身不可见，但它们引发的 DOM 构建异常会在 Elements 面板留下明确痕迹：不是靠看源码，而是看浏览器实际构建出的树。
- 节点边缘出现红色高亮或灰色半透明背景——Chrome/Edge 对非法嵌套的标记，常由控制字符干扰解析顺序触发
- 右键 →
Edit as HTML改一个空格就导致整块结构“跳变”——说明原始 HTML 被浏览器强行重排过，根源常是非法字符导致的 token 解析错位 - 展开某个容器后，内部突然多出一个本不该在那里的父级（比如
footer出现在header里），或出现孤立的灰色斜体节点——这是解析器纠错失败后的残余 - 特别注意
table、ul、ol内部节点突兀缩进断裂：非法字符可能让解析器误判子元素类型，把div当成tr或li处理
用户粘贴内容带 Word 格式时如何预清洗
Word 复制粘贴进富文本编辑器后生成的 HTML，常含大量不可见控制字符（如 、 ）、非法实体（ 变形）、以及零宽空格（u200b），这些都会在服务端解析时引爆。
- 前端提交前就该清洗：用正则
input.value.replace(/[ - - u200b-u200fu2028-u202f]/g, '')干掉常见非法字符 - 后端接收后不能只做
htmlspecialchars()，要额外跑一遍控制字符过滤，尤其注意u200b（零宽空格）和ufeff（BOM） - 若用 TinyMCE 或 Quill，启用
paste_preprocess钩子，在粘贴瞬间剥离不可见字符，比事后修复更可靠 - 数据库存储前加校验：MySQL 中可设
CHECK (content NOT REGEXP '[\x00-\x08\x0b\x0c\x0e-\x1f]')拦截脏数据入库
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
