wkhtmltopdf在ARM设备上需静态链接Qt并适配aarch64架构，否则易因动态库缺失导致段错误；lxml需确认PyPI提供arm64 wheel或改用系统包安装；Go工具链对ARM64原生友好。
HTML本身没有转换函数，真正要选的是解析器、渲染器或绑定层
ARM设备上不存在“HTML转换函数”这种东西——HTML是标记语言，不执行逻辑。你实际需要的，是能把HTML字符串变成可操作DOM、转成PDF、高亮代码、或喂给WebView的工具链。关键不是语法兼容性（所有现代浏览器在ARM上都支持document.querySelector()），而是底层依赖是否适配ARM指令集、能否避免动态链接失败、是否触发硬件加速路径。
lxml在ARM Linux上需确认wheel是否含arm64二进制
lxml在ARM64服务器（如AWS Graviton）或树莓派上容易因缺失预编译wheel报错：Error: Cannot find module './lxml.etree.cpython-*.so'。这不是Python版本问题，而是PyPI上很多lxml包只提供x86_64 wheel。
- 安装前先查包支持：运行
pip debug --verbose确认impl="cp"且arch="arm64" - 优先用系统包管理器：
apt install python3-lxml（Debian/Ubuntu ARM64）比pip install lxml更稳 - 若必须pip安装，加
--only-binary=lxml强制跳过源码编译，或手动指定wheel URL（如从lxml releases找带aarch64字样的whl） - 源码编译时需装
libxml2-dev libxslt-dev，且CC=arm-linux-gnueabihf-gcc指定交叉编译器（树莓派3等旧设备仍用armv7）
wkhtmltopdf在ARM平台必须静态链接Qt，否则段错误
wkhtmltopdf在ARM上崩溃的主因是Qt WebKit动态库缺失或ABI不匹配，尤其在UOS、银河麒麟等国产ARM发行版上。它不会报“找不到libQt5WebKit.so”，而是直接Segmentation fault (core dumped)。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 别用
apt install wkhtmltopdf——系统源里的包几乎全是x86_64或未静态链接 - 编译时必须加
CONFIG+=static和LIBS+=-lssl -lcrypto，否则Qt依赖无法打包进二进制 - qmake配置中显式指定
QMAKE_CC = arm-linux-gnueabihf-gcc和QMAKE_CXX = arm-linux-gnueabihf-g++ - 验证生成的二进制：运行
file wkhtmltopdf，输出应含ARM aarch64而非ELF 64-bit LSB shared object, x86-64
Go写的HTML转换工具（如Glance的HTMLConverter）在ARM上最省心
用Go写的HTML处理工具（比如HTMLConverter这种导出C ABI的静态库）在ARM上天然友好——Go标准库原生支持arm64，编译时加GOARCH=arm64即可生成纯静态二进制，无运行时依赖。
立即学习“前端免费学习笔记（深入）”；
- 调用方（Swift/Objective-C/C#）不用管架构，只要头文件
.h和静态库.a匹配就行 - 像
goldmark（Markdown转HTML）、chroma（语法高亮）这类纯Go库，ARM64性能与x86相当，甚至因内存访问模式优化略快 - 注意cgo导出函数返回
*C.char后，调用方必须主动C.free()，否则ARM设备内存紧张时容易OOM - 若集成进iOS/macOS项目，Xcode里需在Build Settings中设
Excluded Architectures为空，避免误剔arm64
真正卡住ARM HTML工具落地的，从来不是JavaScript API能不能用，而是那些“看不见”的二进制依赖——Qt动态库、Node.js原生模块、WASM文件架构位宽。选工具时，优先看它是否提供arm64预编译产物，或是否能用纯高级语言（Go/Rust）重写核心逻辑。否则，调试段错误的时间会远超写业务逻辑。
