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