为什么MEA Tools的代码库从零开始构建，而不是使用现成的库？

真正从零编写的部分确实是"从零"

以驱动MEA Tools几乎所有PDF相关工具的pdf-lib文件夹为例——从合并PDF、拆分PDF、PDF转Word、填写PDF表单，到加密和水印。这个文件夹包含近37个JavaScript文件，总代码量超过10,000行，全部从零编写：原始PDF对象解析器、分词器、内容流解释器、交叉引用结构重建器，以及把页面渲染成图片的光栅化器。

这意味着当MEA Tools"读取"一个PDF文件时，这不是对别人现成库的调用——有代码真正逐字节解析PDF文件结构，依照规范编写，专门为这些工具的需求定制。其他文件夹也是类似情况：图片压缩逻辑、色彩转换、二维码生成，以及哈希函数——全都是自己的代码，而不是粘贴一个npm包然后import进来。

为什么要费心自己写？

有几个具体原因，不只是技术上的自尊心：

• 文件体积更小。通用库通常被设计得很泛用，以适应多种使用场景——结果是带来了许多不相关的代码。为自身需求定制编写的代码可以精简得多，这一点很重要，因为这一切都运行在用户的浏览器中，而不是资源充足的服务器上。
• 完全掌控行为。如果某种特定PDF出现了奇怪的bug，不需要等待别人库的维护者发布补丁——可以直接剖析和修复，因为所有代码本来就是自己的。
• 没有可能停止维护的依赖项。许多流行的开源库一旦维护者转去忙别的事情就会停止更新。如果工具的根基建立在这之上，风险也会随之而来。
• 确切了解用户数据发生了什么。因为每一行解析代码都是自己写的，没有第三方"黑箱"在不清楚具体操作的情况下处理别人的文件。

但并非一切都从零编写——这是刻意的

为了让这篇文章诚实，而不只是宣传：MEA Tools确实有一些部分使用了第三方库或模型，这是有意识的决定，不是疏忽。

• 照片去背景使用了开源AI模型（U2Net），通过ONNX Runtime运行——这是来自社区的AI推理引擎，不是自己编写的。为几十个工具中的一个重写整个神经网络推理运行时，显然超出了合理的规模。AI模型文件本身托管在MEA的服务器上，而不是依赖第三方CDN——但运行它的引擎依然是ONNX Runtime。
• 图片分辨率放大（upscaler）使用了Real-ESRGAN AI模型，同样通过ONNX Runtime运行，原因相同。
• 从图片/扫描件提取文字（OCR）的两个工具使用了Tesseract.js——一个成熟且广受信任的开源OCR引擎。从零重写OCR引擎本身就是一个独立的研究项目，远超出一个文档转换工具的范畴。

有趣的部分在代码内部：唯一另一个刻意不手动从零编写的部分是用于PDF加密的AES函数——它使用了浏览器内置的Web Crypto API，而不是自制的AES实现。原因在代码注释中写得很清楚：AES用于真正的安全需求（保护PDF内容不被他人查看），而浏览器内置的AES实现已经经过严格审计，并能抵御计时攻击——如果手动重写而没有同等级别的安全审计保证，这是非常危险的。

相比之下，同一批工具中的MD5和RC4哈希函数确实是手动从零编写的——因为那里的MD5/RC4是用于旧版PDF数据格式的需求（而不是用于保护数据机密性），不涉及敏感的安全目的。

这对你作为用户来说为什么重要？

这听起来可能只是幕后的技术细节。但影响是直接可感受到的：专为自身需求定制编写的工具往往运行更轻量、打开更快、行为更可预测——因为没有携带实际用不到的通用代码的负担。而在真正关乎你数据安全的部分，比如PDF加密，选择使用经过验证的实现，实际上比单纯为了一致性而强行手写所有东西更安全。

仍在持续发展

同样需要意识到的是："从零编写"这种方式意味着每个新功能都比直接装一个现成库需要更长的时间。比如单就PDF而言，自建的pdf-lib目前只覆盖了PDF文件所能做到的一部分——PDF格式的世界很广阔，MEA Tools还没有止步于此。MEA Tools整体仍在持续开发和扩充，所以现在的功能范围并非最终版本——会随着时间持续增加。