整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
閱讀本文大概需要 6 分鐘
日常開發(fā)軟件可能會遇到這類小眾需求，導(dǎo)出數(shù)據(jù)到 Word、Excel 以及 PDF文件，如果你使用 C++ 編程語言，那么可以選擇的方案不是很多，恰好最近剛好有這部分需求，整理下這段時間踩過的坑，方便后人
日常開發(fā)的軟件使用最多的應(yīng)該是導(dǎo)出數(shù)據(jù)到 Word 文檔中，目前可以用的方案有這幾種
沒有十全十美的方案，任何方案都存在優(yōu)點和缺點，下面來詳細(xì)看下這幾種方案的優(yōu)缺點以及適用場景
“
原理：事先編輯好一份 Word 模板，需要替換內(nèi)容的 地方預(yù)留好位置，然后使用特殊字段進行標(biāo)記，后面使用代碼進行全量替換即可完成
我們先編輯一份 Word 模板文檔，內(nèi)容大概如下所示：
QFile file("XML-Template.xml");
if (!file.open(QIODevice::ReadOnly))
{
qDebug() << "open xxml file fail. " << file.errorString();
return 0;
}
QByteArray baContent = file.readAll();
file.close();
QString strAllContent = QString::fromLocal8Bit(baContent);
strAllContent.replace("$VALUE0", "1");
strAllContent.replace("$VALUE1", QString::fromLocal8Bit("法外狂徒張三"));
strAllContent.replace("$VALUE2", QString::fromLocal8Bit("考試不合格"));
strAllContent.replace("$VALUE3", "2");
strAllContent.replace("$VALUE4", QString::fromLocal8Bit("李四"));
strAllContent.replace("$VALUE5", QString::fromLocal8Bit("合格"));
QFile newFile("export.doc");
if (!newFile.open(QIODevice::WriteOnly))
{
qDebug() << "file open fail." << newFile.errorString();;
return 0;
}
newFile.write(strAllContent.toLocal8Bit());
newFile.close();
可以看出來這種方式比較繁瑣，重點是編輯固定的模板格式，而且編輯好后保存成XML格式后還需要繼續(xù)調(diào)整，這種 XML 格式標(biāo)簽很多，不小心就修改錯了，導(dǎo)致導(dǎo)出的文檔打不開
這種方式適合模板內(nèi)容不太復(fù)雜，內(nèi)容較少的情況下使用
“
原理：采用 Micro Soft公開的接口進行通訊，進行讀寫時會打開一個 `Word進程來交互
COM 技術(shù)概述
Qt 為我們提供了專門進行交互的類和接口，使用 Qt ActiveX框架就可以很好的完成交互工作
使用時需要引入對應(yīng)的模塊，在 pro 文件引入模塊
QT *= axcontainer
打開文檔寫入內(nèi)容
QAxObject *pWordWidget = new(std::nothrow) QAxObject;
bool bResult = pWordWidget->setControl("word.Application");
if (!bResult)
{
return false;
}
// 設(shè)置是否顯示
pWordWidget->setProperty("Visible", false);
QAxObject *pAllDocuments = pWordWidget->querySubObject("Documents");
if(nullptr == pAllDocuments)
{
return false;
}
// 新建一個空白文檔
pAllDocuments->dynamicCall("Add (void)");
// 獲取激活的文檔并使用
QAxObject *pActiveDocument = pAllDocuments->querySubObject("ActiveDocument");
if(nullptr == pActiveDocument)
{
return false;
}
// 插入字符串
QAxObject *pSelectObj = pWordWidget->querySubObject("Selection");
if (nullptr != pSelectObj)
{
pSelectObj->dynamicCall("TypeText(const QString&)", "公眾號：devstone");
}
……
可以看出來使用起來不難，對于新手友好一點，很多寫入操作方法比較繁瑣，需要自己重新封裝一套接口
這種方式同樣適用于寫入 Excel 文件，后面再說
“
原理：這種方式得益于 Word支持 HTML格式導(dǎo)出渲染顯示，那么反向也可以支持，需要我們拼接 HTML格式內(nèi)容，然后寫入文件保存成 .doc格式
QString HTML2Word::getHtmlContent()
{
QString strHtml = "";
strHtml += "<html>";
strHtml += "<head>";
strHtml += "<title>測試生成word文檔</title>";
strHtml += "<head>";
strHtml += "<body style=\"bgcolor:yellow\">";
strHtml += "<h1 style=\"background-color:red\">測試qt實現(xiàn)生成word文檔</h1>";
strHtml += "<hr>";
strHtml += "<p>這里是插入圖片<img src=\"D:\\title.jpg" alt=\"picture\" width=\"100\" height=\"100\"></p>";
strHtml += "</hr>";
strHtml += "</body>";
strHtml += "</html>";
return strHtml;
}
// 保存寫入文件
QFile file("D:/htmp2Word.doc");
if (!file.open(QIODevice::WriteOnly))
{
return false;
}
QTextStream out(&file);
out << getHtmlContent();
file.close();
這種方式難點在于 HTML格式拼接，任何缺失字段都會導(dǎo)致導(dǎo)出失敗，適合小眾需求下導(dǎo)出
圖片問題其實可以手動進行轉(zhuǎn)化，文檔導(dǎo)出成功后手動拷貝內(nèi)容到新的文檔，這樣圖片就真正插入到文檔中，文檔發(fā)送給別人也不會丟失圖片了
還有一個坑就是：如果你使用 WPS 打開導(dǎo)出的文檔，默認(rèn)顯示的是 web視圖，需要手動進行調(diào)整
某些電腦分辨率變化也會導(dǎo)致生成的文檔中字體等產(chǎn)生變化
可以使用的第三方庫幾乎沒有，網(wǎng)絡(luò)上找到的有這么幾個
DuckX庫 docx庫
在讀寫 Word這部分，C++ 基本沒有可以使用的第三方庫，不像其他語言Java、C#、Python有很多可以選擇，這個痛苦也只有 C++ 程序員能夠理解了吧
所以怎么選擇還是看自己項目需求吧，沒有十全十美的方案
上面說了這么多，都是導(dǎo)出生成 Wrod，那么下面來看看有那些方式可以讀取顯示 Word內(nèi)容
這種需求應(yīng)該不會很多，而且顯示難度更大一些
使用 COM組件方式，即采用 QAxWidget框架顯示 office 文檔內(nèi)容，本質(zhì)上就是在我們編寫的 Qt 界面上嵌入 office 的軟件，這種方式其實和直接打開 Word查看沒有啥區(qū)別，效果、性能上不如直接打開更好一些
目前一般都會采用折中方案，把 Word 轉(zhuǎn)為 PDF 進行預(yù)覽加載顯示，我們知道 PDF 渲染庫比較多，生態(tài)相對來說要好一些，在選擇上就更廣泛些，如何使用后面部分有專門介紹 PDF章節(jié)
目前有一個支持比較好的第三方庫可以使用，整體使用基本可以滿足日常使用
QXlsx
這款開源庫支持跨平臺，Linux、Windows、Mac、IOS、Android，使用方式支持動態(tài)庫調(diào)用和源碼直接集成，非常方便
編譯支持 qmake和cmake，可以根據(jù)你自己的項目直接集成編譯，讀寫速度非?？?/p>
QXlsx::Document xlsx;
// 設(shè)置一些樣式
QXlsx::Format titleFormat;
titleFormat.setBorderStyle(QXlsx::Format::BorderThin); // 邊框樣式
titleFormat.setRowHeight(1,1,30); // 設(shè)置行高
titleFormat.setHorizontalAlignment(QXlsx::Format::AlignHCenter); // 設(shè)置對齊方式
// 插入文本
xlsx.write(1,1, "微信公眾號：devstone", titleFormat);
// 合并單元格
xlsx.mergeCells(QXlsx::CellRange(2,1,4,4), titleFormat);
// 導(dǎo)出保存
xlsx.saveAs("D:/xlsx_export.xlsx");
// 添加工作表
xlsx.addSheet("devstone");
可以看到上手非常容易、各個函數(shù)命名也貼近 Qt Api，是一款非常良心的開源軟件
“
PS:注意該軟件使用 MIT 許可協(xié)議，這樣對于很多個人或者公司來說非常良心，意味著你可以無償使用、修改該項目，但是必須在你項目中也添加同樣的 MIP許可
上面也提到了，還可以使用 COM 組件的方式讀寫 Excel，不過有了這款開源庫基本就可以告別 COM組件方式了
PDF相關(guān)開源庫挺多的，給了 C++ 程序員莫大的幫助，目前可用的主要有這些
其中 mupdf和 poppler 屬于功能強大但是很難編譯的那種，需要有扎實的三方庫編譯能力，否則面對 n 個依賴庫會無從下手
不過可喜的是 Github 上有兩個開源庫可以供選擇
這個庫其實封裝了 pdf.js庫，使用 WebEngine來執(zhí)行 JavaScript進而加載文件
項目地址
這種方式對環(huán)境有特殊要求了，如果你的項目使用的 Qt 版本不支持 WebEngine，那么就無法使用
這個庫是 Qt 官方親自操刀對第三方庫進行了封裝，暴露的 API 和 Qt 類似，使用起來非常舒服
Qt 官方
代碼結(jié)構(gòu)以及使用 Demo
關(guān)于如何使用，官方已經(jīng)給了我們非常詳細(xì)的步驟了，直接跟著下面幾步就 OK 了
官方教程
git clone git://code.qt.io/qt-labs/qtpdf
cd qtpdf
git submodule update --init --recursive
qmake
make
cd examples/pdf/pdfviewer
qmake
make
./pdfviewer /path/to/my/file.pdf
可以看到使用了谷歌開源的 pdfium 三方庫，編譯時需要單獨更新下載這個庫，因為某些原因可能你無法下載，不過好在有人在 GitHub上同步了這個倉庫的鏡像，有條件還是建議直接下載最新穩(wěn)定版的
可正常訪問的倉庫地址：https://github.com/PDFium/PDFium
相關(guān)類可以看這個文檔：https://developers.foxit.com/resources/pdf-sdk/c_api_reference_pdfium/modules.html
“
最后還要注意項目開源協(xié)議：pdfium引擎開始來自于福昕，一個中國本土的軟件公司，Google與其合作最終進行了開源，目前采用的是 BSD 3-Clause 協(xié)議,這種協(xié)議允許開發(fā)者自由使用、修改源代碼，也可以修改后重新發(fā)布，允許閉源進行商業(yè)行為，不過需要你在發(fā)布的產(chǎn)品中包含原作者代碼中的 BSD 協(xié)議
以上就是項目中常用的文檔處理方法總結(jié)，當(dāng)然了肯定也還有其它方案可以實現(xiàn)，畢竟條條大路通羅馬，如果你還要不錯的方案和建議歡迎留言
PS: 以上方案和對應(yīng)的源碼編譯、使用例子會統(tǒng)一上傳到 GitHub對應(yīng)的倉庫，方便后人使用
取之互聯(lián)網(wǎng)、回報互聯(lián)網(wǎng)
原創(chuàng)不易，如果覺得對你有幫助，歡迎點贊、在看、轉(zhuǎn)發(fā)
推薦閱讀
于有人站出來，打算跟 JavaScript 生態(tài)系統(tǒng)正面交鋒了。這家伙知道自己在干什么，而且也描繪出了干掉 JS 之后要創(chuàng)造的美好新世界。
2022 年，前 Stripe 開發(fā)人員 Jared Sumner 發(fā)布了Bun，一種用 Zig 編程語言開發(fā)的運行時。據(jù)我所知，Bun 最初只是種 JavaScript webserver，但在后續(xù)發(fā)展中逐漸醞釀出了全面顛覆 JS 生態(tài)系統(tǒng)的野心。
按我個人的關(guān)注度排序，Bun 的優(yōu)勢主要有以下幾點：
Bun 改朝換代的思路看著非常簡單粗暴——JS 有的我也要有，而且我的要更簡單、更高效。這里沒有小聰明、沒有曲線救國，要的就是正面對抗而且樣樣比 JS 強。用一種低級語言，編寫出運行極快的代碼，這就是 Bun。
Bun 還很年輕，也許還沒準(zhǔn)備好迎接那些令人頭大的真實生產(chǎn)用例。但它確實發(fā)展迅速，所以如果 Bun 真能在幾年后快速占據(jù)市場份額，我也覺得完全在情理之中。
不知道大家在實際工作中有沒有編寫過 JS 或 TS 生產(chǎn)代碼，那種體驗挺難受的。多數(shù)情況下，開源工具和小項目也能良好運轉(zhuǎn)，但一到商業(yè)和企業(yè)級用例上就經(jīng)常掉鏈子。而因為傳統(tǒng)、常規(guī)的路線走不通，企業(yè)只能試遍各種辦法讓項目能在生產(chǎn)環(huán)境中正常起效。
例如，TypeScript 在涉及多位開發(fā)者的項目中解決了不少老大難問題，所以只要 JS 的路子走不通，我們就能隨時引入 TS 進行代碼轉(zhuǎn)換。這里要真心感謝微軟。NPM 對大型項目和單體 repo 來說速度太慢，所以公司可能需要轉(zhuǎn)向 Yarn。這里又要謝謝 Facebook?？傊?，我們就是在拼了命地東拼西湊，最終搞出性能勉強說得過去的成果。
作者提到自己所在企業(yè)的整個單體 repo 執(zhí)行 eslint 需要耗費 79 秒，所以只能單獨配置，保證只對發(fā)生變更的文件執(zhí)行 lint。雖然會引入更多復(fù)雜元素，但也沒有辦法。
總的來說，無數(shù)開發(fā)者都在用自己的辦法加速 JS 工具鏈中的某些特定部分。比如用 Yarn 3 那瘋狂的“即插即用”節(jié)點模塊虛擬化速度來替代 NPM，或者用基于 JSON Schema 的請求解析器解決 Express 的低速問題。其實大多數(shù)原有工具都有類似的問題，而且它們是由 JS 開發(fā)者編寫、專為 JS 開發(fā)者服務(wù)的。用 JS 編寫，就等同于速度很慢……
于是，一些用更快語言編寫的高速工具開始流行起來。每家擁有大型 React 應(yīng)用程序的企業(yè)，肯定都經(jīng)歷過 WebPack 構(gòu)建要花掉整整一分鐘的折磨。為此，他們必須轉(zhuǎn)向用 Go 語言編寫 esbuild。同樣的，其他語言版本的 eslint 替代方案也開始出現(xiàn)，比如用 Rust 重寫 Rome。
Bun 是這種趨勢的自然延續(xù)，但采取的卻是自下而上的推進路徑。這個項目的核心思路就是從零起步、以內(nèi)置“batteries”的方式，用低級語言重寫整個 JavaScript 生態(tài)系統(tǒng)。而且到目前為止，效果還真心不錯。
如果 Bun 只是對所有 JS 輔助工具進行重寫，我當(dāng)然也很歡迎，但那樣的它只能算是 Node.js 的又一個替代品。Bun 并沒有這樣偷懶，它努力讓解釋器本身也快起來。
Bun 是用 Zig 編寫的，而且配合蘋果開發(fā)的 JavaScriptCore，類似于 Node 使用 v8。Zig 是一種新興的低級語言，主要活躍在 C++占主導(dǎo)地位的場景。我不是低級開發(fā)者，所以沒親自用過，更多細(xì)節(jié)就留給其他技術(shù)更強的博主吧。在本文中，大家只要知道 Zig 寫的代碼很快就行了。至于 JavaScriptCore，它的作用跟 v8 一樣，只是 v8 來自谷歌、而它來自蘋果。Safari 和蘋果的很多其他項目都有用到 JavaScriptCore。
Bun 比 Node 到底快多少還沒有定論，但據(jù)稱在某些特定場景下要快得多。很多朋友可能沒經(jīng)歷過 io.js 剛誕生的時代，總結(jié)來說，那時候一個單純能提高解釋器速度的分叉就足以撼動整個 JS 生態(tài)系統(tǒng)。而 Bun 的啟動速度又比 Node 快得多。我自己的親身實驗是 7 毫秒左右，大概比 Node.js 快了 10 倍，所以特別適合無服務(wù)器環(huán)境和邊緣計算場景。
這一波顛覆依靠的不只是速度優(yōu)勢，Bun 還添加了不少優(yōu)秀的標(biāo)準(zhǔn)庫函數(shù)。例如，Bun.write()就是用于編寫文件的新函數(shù)，它會返回一個承諾，而且號稱可以通過更適合的系統(tǒng)調(diào)用進一步加快速度。
說起 Node API，Bun 目前已經(jīng)能支持約 90%的現(xiàn)有 Node API。Node 規(guī)模很大，其中總有一些別說沒用過、可能大家聽都沒聽過的東西（比如 new AsyncLocalStorage() ），所以能支持 90%已經(jīng)很好了。誰會運行 NPM 上的所有包呢？根本不需要，而且基本不影響我們的日常開發(fā)。
順便說一句，TypeScript 在 Bun 這邊可是相當(dāng)有排面，直接調(diào)用 bun my-ts-file.ts 就行。Deno 對 TS 的支持也就這個水平了。使用 Bun 對新項目進行模板化，或者把 bun-types 添加到 tsconfig 當(dāng)中，IDE 中的自動補全功能就將適用于這些新函數(shù)！
Bun 項目最初目標(biāo)之一就是創(chuàng)建一種更快、更強大的 TypeScript 編譯器。這個目標(biāo)現(xiàn)在已經(jīng)實現(xiàn)，同時被淹沒在其他眾多功能中。但目前，它仍然無法支持某些比較高級的 TypeScript 配置和功能，例如裝飾器、tsconfig 中將多個配置合并起來的擴展功能等。
下面來聊 Bun 最振奮人心的能力之一——替代 NPM。它真的很快，能讓人人都滿意那種快。
在 Linux 上，bun install 的包安裝速度可以達到 npm install 的 20 倍到 100 倍。在 macOS 上，也能達到 4 倍到 80 倍。
我敢肯定，沒 cache 快，有 cache 更快，總之就是快。
之前就已經(jīng)有很多方案在努力幫 NPM 提速了。比如大家熟悉的 Yarn Plug-n-Play，它的思路就是徹底放棄 node_modules 文件夾來加快包安裝速度。雖然有一定效果，但在實際使用中，提速并沒有那么顯著，而且還需要處理大量 polyfill 和 escape-hatches 操作。能用是能用，但我個人實在是不想再用、也不打算向大家推薦。
Pnpm 是另一種新興的 NPM 替代方案，在繼續(xù)使用 TypeScript 編寫的同時實現(xiàn)了一部分智能優(yōu)化。在 pnpm 中，node_modules 是通過符號鏈接從全局緩存中訪問的，每個包都能在自己的獨立時間內(nèi)完成安裝，無需等待其他包完成當(dāng)前操作。
Bun 的基本思路跟 NPM 一樣，但速度卻更快。它有自己的 lockfile 格式，而且其中的 node_modules 和 package.json 看起來沒什么變化。如果大家對文件系統(tǒng)調(diào)用比較熟悉，可以結(jié)合低級訪問和快速語言實現(xiàn)極快的安裝效果，而且無需任何花哨的技巧。
現(xiàn)在，Bun 還不提供工作空間支持，所以暫時沒法對接那些期待它來拯救的大型單體 repo（我們的項目也屬于這類）。但好在 Bun 正保持著迅猛的發(fā)展速度，幾周前剛公布的路線圖也提到了工作空間支持。
請注意，大家不用全面轉(zhuǎn)向 Bun 也能把它當(dāng)成包管理器、轉(zhuǎn)譯器或者解釋器。只需要選擇我們需要的部分，丟棄其余的部分就行。我猜 Bun 的初步普及可能也會走這條道路，就是先當(dāng)個好用的包管理器，其他的以后再說。這樣接受門檻會變得更低一些。
Bun 當(dāng)中包含一個用于網(wǎng)絡(luò)瀏覽器的轉(zhuǎn)譯器，這明顯是把矛頭指向了 webpack 和 esbuild。順帶一提，Bun 中的解析器就是 esbuild 解析器的一個 Zig 端口，輕松愉快。
Bun 已經(jīng)支持多種文件類型，css、svg、tsx、jsx、ts 之類的都行。JS 中的 CSS 等高級選項似乎也能在 Bun 上正常工作。
由于 Bun 包含一個帶有幾套內(nèi)置模板的項目腳手架，所以這里我們可以直接調(diào)用：
bun create react my-app
之后，我運行 bun dev 并在瀏覽器里運行了一個 react 應(yīng)用程序。我猜可以把 react-scripts 直接添加到 Bun 替換過的工具列表當(dāng)中。
把文件擴展名從 jsx 改成 tsx，程序就立刻生效了。導(dǎo)入 svg，沒有問題。開發(fā)模式似乎還支持 HMR，也就是前端開發(fā)者在使用 webpack 時的一大必備工具。
那么，轉(zhuǎn)譯器方面還缺什么嗎？缺的還多，畢竟生產(chǎn)環(huán)境的要求可不簡單。首先就是最小化了，這是實際用戶最希望在后續(xù)發(fā)展路線圖上看到的功能。對于大型插件生態(tài)系統(tǒng)來說，還必須要有能夠支持不同文件格式的打包工具。例如，目前.vue 文件和.scss 還沒有實際落地，特別是.scss，這東西幾代開發(fā)者都在用，必須趕緊實現(xiàn)。目前我還不確定 Bun 捆綁器的可插拔性怎么樣，而且最重點的是要直接在框架之內(nèi)解決問題，不要依賴大量外部開源包。
Bun 還把不少傳統(tǒng)意義上的框架元素添加到了標(biāo)準(zhǔn)庫當(dāng)中。就個人而言，我對那些庫類型功能不太感興趣，畢竟 Node 中已經(jīng)有很多適用于 http server 的功能長城了。
Bun 的 webserver 看起來非常簡單。Express 雖然有點落后于時代，但對大多數(shù)開發(fā)者來說仍然夠用（開發(fā)團隊今年還剛剛提供了對承諾的支持）。Bun server 好像跟 Cloudflare Worker 頗為相信。只要 JavaScript 生態(tài)中的其他問題逐一得到解決，也許 Bun 的開發(fā)團隊會轉(zhuǎn)回頭好好打磨一下 webserver 吧。需要注意的是，在某些情況下，巧用系統(tǒng)調(diào)用可以讓 Bun webserver 的速度提高一倍，特別是在文件處理過程中。
至于新的 SQLite 適配器，我覺得之前 Node 中的 sqlite 實現(xiàn)思路有點脫離正常人的腦洞。現(xiàn)在大多數(shù)開發(fā)者會把舊有 sqlite 3 包跟 sqlite 打包器結(jié)合使用，借此實現(xiàn)對承諾的支持。Bun 的解決方案看起來更簡潔，所以就算速度上沒啥大優(yōu)勢，我也愿意用。
我最擔(dān)心的是，Bun 的這么多優(yōu)點難以轉(zhuǎn)化成對社區(qū)成員的實際吸引力。Bun 本身就是 JS 生態(tài)系統(tǒng)的完整替代品，這么巨大的轉(zhuǎn)變一般人恐怕很難快速接受。
Bun 還很年輕，目前沒有完整的說明文檔。對于大多數(shù)問題，我們只能查閱長長的自述文件。但創(chuàng)建一個 docusaurus 站點，再配合具備完整內(nèi)聯(lián)注釋的 TypeScript 類型生成相應(yīng)的 typedoc 并不困難，所以我猜這一點應(yīng)該很快就能解決。
服務(wù)端渲染 React 每秒 HTTP 請求數(shù) (Linux AMD64) 對比，來自 Bun 官網(wǎng)
如果你從來沒聽說過 Deno、也不打算了解，直接跳過這章也行。而且就個人而言，我覺得 Bun 比 Deno 更有搞頭、更有前途。
來自 Node 締造者的 Deno 宣稱解決了一些長期困擾開發(fā)者的老大難問題。它把 es-modules 設(shè)定成默認(rèn)值，引入了第一方 TypeScript 支持（無需在發(fā)布前轉(zhuǎn)譯 NPM 模塊）等等。但在我看來，Deno 在解決老問題的同時，也引入了不少新問題。
首先，Deno 對包解析和語法做的變更過于大刀闊斧，導(dǎo)致沒法跟原有 NPM 生態(tài)系統(tǒng)兼容。換言之，Deno 需要培養(yǎng)起自己的全新庫生態(tài)。雖然 Deno 慢慢開始支持一些早期庫，但我覺得一個項目的影響力會直接決定它的發(fā)展上限，所以 Deno 的邊界估計也就到這了。當(dāng)然也有一些變通方法，比如把 NPM 包轉(zhuǎn)換成 Deno 包的 CDN，但我覺得這不是什么好招。
Deno 還有不少在我看來暴露其半成品身份的問題，比如缺少 package.json。無論是從模塊解析的角度來看，還是從缺少 manifest 文件出發(fā)，Deno 都不允許開發(fā)者為自己的包編寫可擴展元數(shù)據(jù)。GoLang 甚至專門為此引入了 go.mod。
另外，我覺得 Deno 設(shè)計中的沙箱/權(quán)限系統(tǒng)應(yīng)該是正確的思路，只是粒度不夠細(xì)。它位于整個項目的頂層、脫離了包層次，這意味著大型應(yīng)用程序最終還是需要所有權(quán)限，于是問題又回到了原點。而且作為一家安全公司，我們對 Deno 無法保護大型應(yīng)用免受供應(yīng)鏈攻擊而頗感失望。當(dāng)然，Bun 也沒說打算如何解決這個問題，我這里只是發(fā)泄一下自己的不滿。
所以總結(jié)起來：Bun 擁有遠(yuǎn)超 Deno 的發(fā)展?jié)摿Α?span style="color: #1C1E21; --tt-darkmode-color: #A0A3A8;">具體原因如下：
如上所述，Rome 就是個驗證器。Rome 的維護者們已經(jīng)開始用 Rust 代替 JS 進行重寫了，而且 79 秒的驗證時長也有點夸張。（不騙人，我們的 eslint 就是用了 79 秒。）
從路線圖來看，Rome 還打算引入捆綁器、文檔生成器、壓縮器、類型檢查器、測試框架等等。但這一切尚未完成，而 Bun 明顯已經(jīng)走得更遠(yuǎn)。至少 Rome 還沒開始重寫 Node 核心本身，所以我覺得它的影響力也就差不多這樣了。
總之，很多項目都發(fā)現(xiàn)了 Node 生態(tài)系統(tǒng)中的現(xiàn)有問題，而且各自嘗試在統(tǒng)一的高性能框架中將其一舉解決。接下來，就看誰發(fā)展得更快了。
這里我想把視野縮小一點，通過具體案例聊聊開源世界中的生態(tài)陣營是怎么產(chǎn)生的。
相信很多 Node 開發(fā)者都知道 Jest 是怎樣力壓 Mocha 測試框架，一路迅猛崛起的。Mocha 想當(dāng)年也是人們首選的測試運行程序，效果不錯而且語法優(yōu)秀，但只要涉及更復(fù)雜的需求或者斷言，就得引入其他模塊和插件。好在有了社區(qū)協(xié)作，插件也不算太難找。總之，開發(fā)者需要具備更廣泛的知識才能引入相應(yīng)的庫。
后來 Facebook 搞出了 Jest，一套內(nèi)含“batteries”的測試框架。它借鑒了 Mocha 語法和庫，并把一切整合到了單一框架中。Jest 什么都能解決，從偽造時間到需求的檢測和模擬。Jest 也有擴展空間，但我在實際工作中就用過一次。大部分概念驗證和設(shè)計都是由 Mocha 承擔(dān)的，作為后來者的 Jest 只是把成果統(tǒng)一了起來并使其變得更易于訪問。雖然 Mocha 也不乏鐵桿粉絲，但 Jest 確實更受歡迎。
開源世界中有很多這樣的案例。首創(chuàng)解決方案拿下先發(fā)優(yōu)勢，而后續(xù)一旦增長乏力，就會有熱心的開發(fā)商把功能整合起來。這也讓我想到了 Linux 大家族還未統(tǒng)一時的 systemd。如今，systemd 幾乎可以管理大多數(shù) Linux 發(fā)行版上的所有內(nèi)容，而 Bun 也許會以同樣的方式席卷整個 JavaScript 世界。
我意識到從開源的角度來看，這種合并和統(tǒng)一似乎與開源精神相悖，但用大量庫實現(xiàn)簡單需求確實已經(jīng)成為折磨開發(fā)者們的痛點。而且如果每個庫都有相應(yīng)的維護團隊，那惡意黑客通過簡單的偽造郵件域就能實施供應(yīng)鏈攻擊。我們不想這樣，但現(xiàn)實就是如此殘酷。老手尚且容易中招，更遑論剛接觸大量名稱、還不熟悉種種語言的新人了。所以從務(wù)實的角度出發(fā)，我覺得很多朋友應(yīng)該跟我一樣，并不覺得把更多常用功能引入標(biāo)準(zhǔn)庫、將多種開發(fā)工具整合進統(tǒng)一框架屬于歷史的倒退。
截至 2022 年 7 月，Bun 還是沒有做好進軍生產(chǎn)環(huán)境的準(zhǔn)備，但我強烈建議大家自己裝上試一試。整個流程非常便捷，而且我覺得現(xiàn)在的 Bun 已經(jīng)足夠應(yīng)付小型子項目或者公司里的簡單內(nèi)部儀表板了。
我不敢說 Bun 在未來幾年能否甚至如何重塑 JavaScript 的面貌，但我真心對它的發(fā)展充滿期待。
原文鏈接：
https://www.lunasec.io/docs/blog/bun-first-look/
者：陳吉
轉(zhuǎn)發(fā)鏈接：https://mp.weixin.qq.com/s/HweEFh78WXLawyQr_Vsl5g
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
