CPU主频低于2GHz时应选htmlq或pup：htmlq依赖libxml2、适合规范HTML，pup用Go编写、容错性强但体积略大；禁用BeautifulSoup等内存大户，管道处理、禁缓存、不落地文件，强制指定编码防探测开销。
直接看硬件配置，别猜。CPU弱、内存小、没独立显卡的终端，就别硬上带语法树解析或实时预览的HTML格式化工具——它们不是“慢”，是根本跑不起来。
CPU主频低于2GHz时该用什么命令行工具
这时候 htmlq 和 pup 是唯二靠谱选择。它们不启动JS引擎、不加载DOM树、不渲染样式，纯流式解析，单核100%也扛得住。
-
htmlq依赖libxml2，适合结构规整的HTML；遇到自闭合标签缺失（如<br>写成<br/>）或嵌套错乱时容易报错退出 -
pup用Go写的解析器更宽容，能吞掉大部分 malformed HTML，但二进制体积略大（约8MB），在ARMv7旧设备上首次运行可能稍慢 - 别碰
BeautifulSoup+ Python：光Python解释器冷启动就要150MB内存+300ms，再加lxml解析器，CPU弱机上格式化一个5KB文件要等2秒以上
内存 ≤ 1.5GB 的Linux终端怎么避免OOM
关键不是选哪个工具，而是怎么调用它。所有HTML格式化操作必须走管道、禁缓存、不落地临时文件。
- 用
curl -s https://example.com | htmlq "title" | sed 's/^ *//; s/ *$//' | fmt -w 80这类链式命令，全程无中间文件，内存峰值压在10MB内 - 禁止用
$(cat file.html)或python3 -c "from bs4 import BeautifulSoup; print(BeautifulSoup(open('file.html').read()).prettify())"—— 这种写法会把整个HTML一次性读进内存，1MB文件就吃掉300MB RSS - 如果非得用Python脚本，务必加
sys.setrecursionlimit(100)并用iterparse替代BeautifulSoup，否则递归解析嵌套深的表格会直接栈溢出
GPU加速对HTML格式化工具毫无意义
格式化是文本重排，不是渲染。will-change、translateZ(0)、WebView2这些词跟它完全无关。所谓“GPU加速HTML格式化”是营销话术，实际只是把解析逻辑从主线程挪到WebWorker——而终端工具根本没WebWorker。
立即学习“前端免费学习笔记（深入）”；
- 浏览器里打开网页版格式化工具（比如FreeFormatter）确实会受益于GPU加速，但那是为了渲染右侧预览窗，不是为了左边的代码格式化逻辑
- 如果你在Chrome里跑一个Node.js写的格式化CLI（通过chrome://inspect调试），开启硬件加速只影响DevTools界面流畅度，不影响
js-beautify的执行速度 - 真正在意性能？删掉所有
prettify类函数里的正则全局匹配（/g标志），改用indexOf+ 字符串切片——这比换显卡管用十倍
最容易被忽略的一点：很多工具默认启用“自动检测编码”，会在文件头扫几百字节找BOM或。在低算力终端上，这个动作比格式化本身还耗时。要么加 --encoding utf-8 强制指定，要么用 iconv -f utf-8 -t utf-8 //IGNORE 预清洗输入流——别让编码探测成为瓶颈。
