phpEnv 不内置 tidy 扩展，需手动确认 DLL 存在、启用 extension=php_tidy.dll、重启服务并验证；启用后优先用 tidy_repair_string() 显式修复 HTML，注意输入校验、编码一致性和 XSS 防护。
phpEnv 本身不内置 tidy 扩展，必须手动启用 —— 否则调用 tidy_parse_string() 或实例化 Tidy 类会直接报 Fatal error: Uncaught Error: Class "Tidy" not found。
确认 phpEnv 当前 PHP 版本是否支持 tidy
phpEnv 是 Windows 下的多版本 PHP 环境管理工具，它依赖你安装的每个 PHP 版本自身是否编译了 tidy 扩展。不是所有预编译的 PHP 二进制包都默认开启该扩展：
- 打开 phpEnv 控制面板 → 查看当前激活的 PHP 版本（如
php-8.2.12-nts-VS17-x64） - 在对应 PHP 安装目录下检查：
ext\php_tidy.dll是否存在（路径类似C:\phpEnv\php\php-8.2.12-nts-VS17-x64\ext\php_tidy.dll） - 若不存在，说明该版本未打包
tidy，需换用带tidy的 PHP 构建版，或自行编译（极不推荐）
在 phpEnv 中启用 tidy 扩展（Windows）
即使 php_tidy.dll 存在，也需显式启用。phpEnv 的配置文件实际指向各 PHP 版本独立的 php.ini：
- 用 phpEnv 面板点击「编辑 php.ini」，或手动打开对应版本的
php.ini（如C:\phpEnv\php\php-8.2.12-nts-VS17-x64\php.ini） - 搜索
;extension=php_tidy.dll，去掉前面的分号，改为extension=php_tidy.dll - 确保
extension_dir指向正确的ext目录（通常 phpEnv 已配好，但可检查是否为ext而非绝对路径） - 重启 Web 服务（Apache/Nginx）或 CLI 环境（关掉再开命令行）
- 运行
php -m | findstr tidy，输出tidy即表示加载成功
用 tidy::repairString 修复 HTML 常见问题
启用后，tidy_repair_string() 是最轻量、最常用的修复方式，适合模板渲染后、用户提交后等场景做兜底清洗：
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
tidy.clean_output = On（PHP INI 中的全局开关），它会干扰响应头、破坏 UTF-8 BOM、甚至导致乱码；始终用函数/类显式调用 - 常见修复目标：自动闭合错位标签（
<p><b>text</p></b>→ 正确嵌套）、补全缺失的<html><body>、转义非法字符 - 关键配置项建议：
$config = [ 'output-xhtml' => true, 'show-body-only' => false, 'clean' => true, 'wrap' => 0, // 不折行，保持原始结构 'indent' => true, 'indent-spaces' => 2, 'doctype' => 'omit', // 避免插入多余 doctype 干扰已有文档 ]; - 示例调用：
$dirty = '<p>Hello <b>world!</p><div><h1>Title</h2></div>'; $clean = tidy_repair_string($dirty, $config, 'UTF8'); echo htmlspecialchars($clean); // 输出前务必转义，避免 XSS 风险
为什么 tidy_parse_string() 返回空或报 Warning
这个错误大多不是代码写错，而是环境或输入层面的问题：
-
tidy_parse_string()要求输入是合法字符串，不能是null、false或未定义变量；建议先is_string($html) && trim($html)校验 - 编码不匹配：即使指定了
'UTF8'，若原始字符串含 GBK 字节但被当 UTF-8 解析，tidy会静默失败；可用mb_detect_encoding()辅助判断 - 内存限制：大 HTML（>2MB）可能触发
Allowed memory size exhausted；tidy不支持流式处理，超限时只能切片或换用其他方案（如DOMDocument+ 自定义修复逻辑） - Windows 下路径分隔符不影响，但若配置数组里用了中文冒号、全角空格等隐藏字符，会导致解析失败且无明确提示
真正麻烦的不是怎么调用 tidy_repair_string()，而是它无法识别语义错误（比如把 <div> 当作行内元素强行扁平化），也不修复 JS/CSS 逻辑错误。它只管标签结构合规性 —— 这一点很容易被当成“万能修复”，结果上线后才发现表单字段丢失、事件绑定失效。
