HTML本身是纯文本，无需编译；所谓“交叉编译HTML工具”实为交叉编译其背后的原生依赖（如wkhtmltopdf、pdf2htmlEX、Node.js等），需严格匹配目标架构（aarch64/armv7/riscv64）、系统（linux/elf）及ABI（gnueabihf/gnu），并确保sysroot与目标板libc版本一致。
HTML 本身没有“函数工具”可交叉编译——它不是编程语言，不生成机器码。所谓“HTML 工具”在非 x86 架构（如 ARM、RISC-V）上出问题，99% 是因为背后依赖的二进制组件（浏览器引擎、PDF 转 HTML 工具、静态站点生成器等）没用对架构适配的版本，而不是 HTML 写错了。
为什么不能直接 cross-compile HTML
HTML 文件是纯文本，cp index.html target/ 就完事，根本不需要编译。真正需要“交叉”的，是那些处理 HTML 的原生程序：
-
wkhtmltopdf：底层调用 Qt WebKit，必须为 ARM 或 RISC-V 编译其二进制和所有依赖（libpng、freetype、openssl 等） -
pdf2htmlEX：依赖poppler和cairo，这两个库必须用arm-linux-gnueabihf-gcc或riscv64-linux-gnu-gcc重新构建 -
esbuild、vite等前端构建工具：Node.js 二进制本身就得是 ARM64 版；若用预编译二进制（.tar.gz），必须确认下载页明确标注linux-arm64或darwin-arm64
ARM/RISC-V 上验证 HTML 工具是否真可用
别信官网“支持多平台”的宣传，自己动手验：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 在目标设备终端运行：
file $(which wkhtmltopdf)，输出必须含ARM aarch64或RISC-V，而非x86-64 - 执行：
ldd $(which pdf2htmlEX)，所有依赖路径应指向/usr/arm-linux-gnueabihf/lib类目录，而非宿主机的/usr/lib/x86_64-linux-gnu - 运行：
node -p "process.arch"，返回arm64或riscv64才算 Node.js 本体已正确安装 - 如果工具报
cannot execute binary file: Exec format error，就是典型的架构错配，不是权限或路径问题
选工具链时盯死三个字段：架构、系统、ABI
交叉编译器名字不是随便起的，aarch64-linux-gnu-gcc 这类前缀必须和目标板完全匹配：
立即学习“前端免费学习笔记（深入）”；
-
aarch64≠arm：前者是 ARM64（树莓派 4/5、Mac M 系列），后者是 ARM32（旧树莓派 Zero、Cortex-A7 板） -
-linux-表示目标有完整 Linux + glibc，适合 Debian/Ubuntu ARM；-elf-表示裸机或 uClibc，常见于 OpenWrt 或 RTOS 设备 -
-gnueabihf中的hf指硬浮点，现在绝大多数 ARM Linux 板都要求这个；若用gnueabi（软浮点），会因 ABI 不兼容导致undefined symbol: __aeabi_dadd类错误 - 查目标板真实架构：在板子上跑
uname -m（输出aarch64或armv7l），再对照选工具链，别只看芯片型号
最容易被忽略的是 sysroot 与目标板 libc 版本的咬合——哪怕工具链选对了，--sysroot 指向的头文件和库如果来自 Debian 12，而你的板子跑的是 Buildroot 2023.02（glibc 2.37），链接时可能不报错，但运行时报 version `GLIBC_2.38' not found。这种问题不会在编译阶段暴露，得在目标板上用 readelf -d ./tool | grep NEEDED 对照 /lib/ld-linux-aarch64.so.1 的实际路径才能定位。
