LibMN Vendor Globals
LibMN会在启动阶段加载一组第三方库并把全局对象暴露到JSContext。这里的重点不是重复上游全部API，而是告诉你“LibMN当前实际依赖了哪些能力”。
第三方全局对象清单
Section titled “第三方全局对象清单”| 全局对象 | 来源模块 | LibMN已使用能力 | 官方文档 |
|---|---|---|---|
CryptoJS | vendor/CryptoJS | AES.encrypt/decrypt、MD5、SHA256、enc.Base64、enc.Utf8、lib.WordArray.create | CryptoJS |
marked | vendor/marked | marked.parse、marked.lexer | Marked |
mustache | vendor/mustache | mustache.render、mustache.parse | mustache.js |
Segmentit | vendor/segmentit | Segmentit.useDefault、Segmentit.Segment | Segmentit |
jsonrepair | vendor/jsonrepair | jsonrepair(...) | jsonrepair |
pako | vendor/pako | pako.gzip、pako.ungzip | pako |
LZString | vendor/lz-string | compressToBase64、decompressFromBase64 | LZString |
PDFTools | vendor/pdf-bridge-core | convertImageBase64ToPdfBase64、extractPage | AddonLib仓库 |
依赖策略建议
Section titled “依赖策略建议”- 你的业务代码若直接调用这些全局对象，等于直接承担第三方升级风险。
- 若LibMN中已有对应封装，优先走
MNUtil或相关包装类，避免把业务和vendor细节绑死。 - 只有在封装能力不足时再直接访问vendor全局，并在插件内注明版本假设。
- 误区1:把vendor全局当成LibMN稳定API。 说明:它们的稳定性由上游库决定，不由LibMN承诺。
- 误区2:忽略二进制和编码边界。
说明:涉及Base64、压缩、PDF转换时，优先复用
DataConverter和MNUtil现成通路。 - 误区3:只看单次调用成功就上线。 说明:应在不同文档类型、不同笔记本规模下做回归验证。