畢業半年多了，回顧從大學到現在搞過的很有意思的開源項目
回想當年，在高考結束後我的分數並不高，然後被調劑到了工業設計，再到後來感覺對計算機更感興趣，於是對了很久的線努力轉專業到了計算機，之後廢了九牛二虎之力在大二一年修完了計算機專業大一大二兩年的課程，到了大三開始搞事就開始做了一些項目。我發現項目做多了就很容易將項目串聯起來，這點非常有意思。
本着分享與開源的精神，我與大家分享我的項目經驗，我也就是憑藉着這些項目成功在23屆的秋招混進了字節，老大後來跟我說我是23屆唯一一個雙非進入我們大團隊的，雖然我可能是當時秋招最菜的一個，但是最終還是混進去了，所以也算是希望分享一下爲之付出的努力，與君共勉。計算機還是非常有意思的，我也希望能夠保持對於技術的好奇心，同樣也希望能做出一些有意思的項目來獲得一絲成就感。
實際上我也只是昨天突發奇想想總結分享一下我做過的項目，因爲寫過的東西還是比較多的，所以也總結了好久。其實這其中我覺得最重要的問題是爲什麼要做這些項目，有些是想解決平時遇到的問題，比如學校App不好用就做個好用的、網頁不讓複製我就做個解除複製限制的，也有些是想提升技術水平做的，比如我寫過的Webpack相關的、用Canvas實現的簡歷編輯器，還有一些是希望深入研究的，比如在線文檔協同系列、富文本編輯器相關的項目。下面介紹的都是我的開源項目，內容基本也是按照時間線來的，也歡迎關注我的 GitHub:WindrunnerMax 。
此外需要聲明的是，這很像是一篇論文的綜述，文章的信息密度非常高，特別是很多與項目相關的鏈接，如果從零開始接受相關的內容還是需要一些時間的。
山科小站小程序
首先說說爲什麼要做這個小程序，這其中有個背景是當時學校有個查各類信息的軟件叫智校園，但是這個App很不好用，經常崩潰，在某一天我上午第一節課下課後這個App就打不開了，導致我想查個自習室都查不了，當時我在J7教學樓爬了四層樓都未找到自習室，當時就覺得很煩，於是就想自己做一個，不用這個了。
當時我還算是個計算機小白，畢竟在課上老師們大都還是照本宣科，書本上的東西也都比較死板，我就只能自己研究。回去之後我大概研究了兩種方案，分別是搞App逆向看是否有什麼邏輯問題，抓包看是否是數據問題。首先我是逆向了這個包沒看出什麼邏輯的毛病，不過也不是沒有收穫，這時候我拿到了接口請求的地址，然後我就測試請求是否有問題，這一測我就發現了問題所在，僅僅是一個拿初始化數據的接口失敗了而已，而這個數據在我這裏完全可以跳過，畢竟我只需要手動在我自己的服務器上維護這部分數據即可，於是配合之前逆向拿到的接口，一個全新的小程序就上線了，並且還集成了很多數據源擴展了很多功能。
最開始的時候只是我自己在用，第一版本是我在上課期間不務正業一個上午寫完的，做的也比較粗糙，在更新幾版之後，幾乎全校的同學都用上了，數據大家可以看下。
再到後期因爲很多原因比如多場景、小程序認證等問題，我又更新了很多個小程序以及App版本 GitHub:SHST-SDUST 。我個人覺得如果能夠做一個大家都用的項目，並且能夠不斷將學習到的新知識應用到其中，比如我曾經嘗試過遷移TS 山科小站小程序，以及做過組件庫的封裝 微信小程序校歷組件 GitHub:Campus，以及後期我從UniApp框架遷移到了Taro，同樣也是從Vue遷移到了React實現。這樣的項目會比純技術的項目比如各種學習寫mini框架會更有業務價值一些，不過這是兩個方向上的價值，如果能結合技術和業務價值那是最好的。此外我覺得面試官同樣也希望能夠希望候選人能夠在生活中運用自己的技術解決問題，能夠保持對於技術的熱愛與好奇心，這樣更容易跟面試官聊到一起。也可以參考下當時我秋招時簡歷上對於項目的描述，PS: 數據並不是最新的。
實際上從本質來說這個小程序就是單純的爬蟲項目，在我對爬蟲比較瞭解之後，我還做了一些有意思的事情，大家可能或多或少都受到過學校在各種平臺/App上刷任務的通知，爲了減少我自己的工作量，在當時我還做了個爬蟲來幫助我們全班同學刷評論 GitHub:Younger ，幫了團支書一個大忙。還有一個是一個小遊戲的輔助 GitHub:EliminVirus ，當時在朋友的帶領下玩了消滅病毒這個小遊戲，這個小遊戲真的有意思，但是憑藉我風騷的走位打了十幾次硬是過不去230關，於是便有了這個輔助腳本，這個腳本不僅僅是一個爬蟲，這其中還涉及到逆向微信小程序、微信ROOT抓包等知識，並且還寫了文章 手機抓包HTTPS (Fiddler & Packet Capture) Recover刷機簡介，此外還有一些諸如校園網認證的自動登錄 GitHub:GIWIFI 之類的就不過多介紹了。
強智教務系統驗證碼識別
在實現山科小站小程序的時候，其中還有一個很大的問題是驗證碼需要識別，當時對於驗證碼識別的方法不是很懂，於是邊學邊查，最開始的時候就是用的最基本的OpenCV來處理像素，即使這個驗證碼很簡單，但是同樣是因爲我對像素處理的不好導致識別率很低，經常要刷新幾次才能成功識別。
到了後來不斷完善了識別的能力，於是將其抽離出來獨立出了驗證碼識別的倉庫。在做上邊介紹的刷評論 GitHub:Younger 腳本時，驗證碼變得很複雜，此時通過像素來處理就變的很喫力，於是學習了通過CNN來處理驗證碼 GitHub:Example，並且到了後期搞了腳本的腳本用來實現自動訓練的能力，並且也將其應用到了強智的驗證碼識別當中。
再到後來，因爲在多種語言上的需要，將其封裝了Js腳本的實現，幫助我在網頁上登錄強智的時候可以自動識別驗證碼而不需要我再手動輸入了，再到後來因爲學校的教務系統開啓了公網訪問，並且部署了HTTPS證書，國內的公網網站通常都是需要備案的，所以在此基礎上我通過小程序 GitHub:SHST-ULTRA 實現了直接請求教務系統的方案，這意味着只要網絡環境允許，小程序可以一直運行而不需要我的服務器介入。
飛機大戰
這是之前跟@FubinSama一起做的小學期作業，C++(MFC)實現的飛機大戰，雖然代碼寫的很爛但是我覺得還是很有意思的，也算是在前端領域之外的技術擴展。
文本選中複製
這個項目應該很多同學都用過，在GreasyFork上的下載安裝量已經超過260萬了，這其中還不包括其他下載渠道比如GitHub、腳本貓等等。最開始做這個項目的原因是老師讓我們寫某個報告，然後我就準備先“參考”着看看網上的內容，發現很多類似的文庫網站都不讓複製，所以便有了這個腳本 文本選中複製。
雖然這僅僅是一個解除網頁複製限制的腳本，但是其中卻涉及到很多技術細節，比如在調試的時候我應該怎麼確定我剪貼板裏有什麼數據 Canvas圖形編輯器-我的剪貼板裏究竟有什麼數據 、我應該怎麼寫腳本 深入淺出腳本管理器與油猴腳本。如果遇到的都是基本的DOM文本還好說，畢竟無論如何文本都是下載到本地並且在DOM樹上，無論我怎麼處理都可以，但是如果是Canvas繪製的文本應該如何處理、如何設計更加通用的方案、如何適配的各個網站並且管理各個模塊、如何將數據寫到剪貼板等等都是需要考慮的，當然最難的還是調試這個網站爲什麼不能複製。之前我遇到的一個最離譜的是，瀏覽器在選中文本時焦點需要在文本上，而某網站有個按鈕一直在搶焦點，這樣的話用戶就不能複製了，非常的離譜。在這裏也可以參考下當時我秋招時簡歷上對於項目的描述，PS: 數據並不是最新的。
在後期我發現有人做了個瀏覽器擴展，其中嵌入了我的代碼而且還是我打包過後的GPL協議的代碼，最離譜的是其中還加了廣告，此外再加上我也想學習一下瀏覽器拓展，於是我也就做了一個瀏覽器拓展，首先從零使用Rspack搭建了Chrome擴展的開發環境 從零實現的Chrome擴展，並且研究了腳本管理器的實現 從油猴腳本管理器的角度審視Chrome擴展 ，畢竟我是相當於從腳本管理器的基礎上再做一套瀏覽器拓展的實現 GitHub:ForceCopy 。再之後因爲Chrome主推V3版本的瀏覽器擴展實現，而FireFox主推V2版本的瀏覽器擴展實現，我還實現了一套兼容方案 初探webpack之單應用多端構建。實際上我的瀏覽器插件同樣也在這個倉庫裏，這個倉庫是個MonoRepo，所有寫過的腳本都在其中。
博客
我的博客已經寫了非常久了，在博客分支中已有455篇文章，倉庫已有1.5k的star，這是切切實實從前端小白開始慢慢積攢寫起來的文章，倉庫的簡介是“前端基礎 個人博客 學習筆記”，所以如果按照目錄一點點開始看的話，最開始的時候能夠感受到特別簡單，都是基礎的HTML CSS JavaScript，然後越往後會越發的上強度，因爲這實際上就是我的學習歷程，都是這幾年來由淺入深慢慢學習的過程。
寫到這裏我想起來之前我在羣裏說的暴論，把我的博客學明白了進字節應該問題不大，當然在這裏也僅供參考，還有個例子是有位同學把我所有的文章都打印出來學習，最後也是雙非進了字節，當然能進字節跟他自己的努力是分不開的，但是我的博客肯定也是起到了一點作用，要不誰會閒的沒事畫上百大洋去打印文章，畢竟一百大洋還是能喫不少好東西的。此外很多同學去買一些這種課那種課，有我免費的博客不看而非得去花錢買課是何必呢，我寫的內容也都是由淺入深，特別是我的行文風格就是把問題寫的特別詳細，如果從頭開始看基本不會出現理解不了的情況，因爲我寫文章同樣也還是要給自己看的，時間太長我怕我自己都會忘所以對於問題的描述以及相關思考都寫的非常詳細，基本都會配有DEMO可以幫助理解。
這裏還要引用一下我README的內容，這是一個前端小白的學習歷程，如果只學習而不記錄點什麼那基本就等於白學了。這個版本庫的名字EveryDay就是希望激勵我能夠每天學習，下面的文章就是從2020.02.25開始積累的文章，都是參考衆多文章歸納整理學習而寫的，文章包括了HTML基礎、CSS基礎、JavaScript基礎與拓展、Browser瀏覽器相關、Vue使用與分析、React使用與分析、Plugin插件相關、Patterns設計模式、Linux命令、LeetCode題解等類別，內容都是比較基礎的，畢竟我也還是個小白，此外基本上每個示例都是本着能夠即時運行爲目標的，新建一個html文件複製之後即可在瀏覽器運行或者直接可以在console中運行。如果想按照我寫的順序進行閱讀的話可以 查看目錄 ，另外如果想更條理地查看的話可以訪問 我的博客，博客同時也是本版本庫的gh-pages分支，是作爲純靜態頁面搭建在Git Pages上的，使用jsdelivr以及cloudflare作爲緩存緩解國內訪問速度問題。後期還在gh-pages-ssg分支上部署了SSG版本的 新版博客，並且藉助ChatGPT提供了英文翻譯版本，分支是部署在Vercel上來緩解國內訪問速度問題。在博客中的內容就相對比較多了，除了學習筆記之外還有一些做項目時的記錄以及遇到的坑等。
文檔編輯器
初探富文本之富文本概述
初探富文本之編輯器引擎
初探富文本之OT協同算法
初探富文本之CRDT協同算法
初探富文本之OT協同實例
初探富文本之CRDT協同實例
初探富文本之React組件實時預覽
初探富文本之富文本diff算法與文檔對比視圖的實現
在實習的時候，在偶然的機會上我接觸到了富文本編輯器，並且感覺對在線文檔產生了比較大的興趣，本來我想着在公司裏實踐一下，但是因爲業務線不同並且本身不賺錢的或者說收益比較低的變更，在商業排序上是比較靠後的，所以我就想自己做一個並且實踐一下。在這其中學習了很多富文本的知識 基於slate構建文檔編輯器，對於Rollup打包工具也有更深的瞭解 Rollup的基本使用，學習併發布了NPM包以便複用富文本能力，同樣也有部署在GitPages的 在線DEMO。
在現在看來，當時很多設計都是有問題的，插件化這部分設計不是很完善，Core模塊也沒有真正完整抽離出來，並且代碼寫的也並沒有那麼完善，但是這個編輯器爲我以後做的工作打下了基礎，並且不知道大家是否看到在文中第一段我說的“我發現項目做多了就很容易將項目串聯起來，這點非常有意思”，這個文檔編輯器就在我很多項目中集成。
同樣引用一下README的內容，基於slate.js構建的文檔編輯器，slate提供了控制富文本的core，簡單來說他本身並不提供各種富文本編輯功能，所有的富文本功能都需要自己來通過其提供的API來實現，甚至他的插件機制也需要通過自己來拓展，所以在插件的實現方面就需要自己制定一些策略。在交互與ui方面對於飛書文檔的參考比較多，整體來說坑也是比較多的，尤其是在做交互策略方面，不過做好兜底以後實現基本的文檔編輯器功能是沒有問題的。
簡歷編輯器
依舊先說說爲什麼要做這個項目，在這裏主要是遇到了一個問題，當時正值秋招時期，我也爲怎麼更新簡歷發愁，於是我借了學長的某簡歷平臺賬號想做來個簡歷，但是模版嘛你懂的，很多細節都不滿意，限制太多，經常要麼就是某個模塊的內容必須要按照固定格式寫，還有諸如行間距等內容都不能調，要麼就是寫的內容比較多，本來預覽的時候還挺好，導出的時候PDF就超過了一頁。
在某個夜晚我正在洗澡，然後靈光一閃我爲什麼不自己做一個簡歷編輯器呢，我設想的簡歷編輯器是什麼樣子的，那一定是自由拖拽調整位置、自由調整大小、導出的簡歷保證是一頁，那麼這不就是一個很好的低代碼產品嘛！在專有領域上低代碼還是有價值的，並且還能夠串聯我上邊的文檔編輯器項目！簡直是一舉多得，於是這個項目便被確立了起來 基於NoCode構建簡歷編輯器。
實際上我秋招的簡歷就是用我的這個簡歷編輯器實現的 在線DEMO，前文中項目介紹的簡歷截圖也就是用這個項目生成的，這同樣也是我說的項目串聯中的一環，我自己的簡歷是用我自己的項目實現的，並且這個項目還串聯了我的富文本項目，這可以稱作項目的自舉。
Webpack相關
初探webpack之編寫plugin
初探webpack之編寫loader
初探webpack之從零搭建Vue開發環境
初探webpack之單應用多端構建
作爲專業搞前端的，不理解Webpack的打包實現顯然是不合適的，所以我也學習過一些Webpack的實踐，並且寫了相關博客和DEMO。目前看起來在工作中學會這些暫時是足夠的，如果有再深入的使用的話肯定還需要繼續學習並輸出文章。
此外，我還是覺得我們學習了東西最重要的還是解決問題，例如我學習了Webpack的plugin和loader之後，確確實實幫我解決了實現瀏覽器擴展的時候兼容Chrome和FireFox的問題 GitHub:Script 。
React在線預覽
這個項目是與工作內容有關係的，在實現某個需求的時候，我們需要實現一種類似於動態編譯的能力，當時敲定的實現是基於MarkDown的方案，後邊恰逢週末我就趁着這兩天時間調研並開始寫了這個博客 初探富文本之React組件實時預覽(React Playground)，後邊也成功說服了大家，項目的方案也更換爲基於這個方案的類似實現。
大家可能也注意到了上邊我引用的博客還是與富文本相關的，那麼也就是說這個項目又成功串聯了我的富文本項目，實際上在ReactLive的 在線DEMO 以及文檔編輯器的 在線DEMO 中都有實現，在ReactLive中是與博客內容完整相關的DEMO，其中還涉及到了多個編譯器性能測試的相關部分。
實際上這個項目在文檔站中的應用場景會比較契合一些，在一些場景中比如組件庫的文檔編寫時，我們希望能夠有實時預覽的能力，也就是用戶可以在文檔中直接編寫代碼，然後在頁面中實時預覽，這樣可以讓用戶更加直觀的瞭解組件的使用方式，這也是很多組件庫文檔中都會有的一個功能。
在線文檔協同
初探富文本之OT協同算法
初探富文本之CRDT協同算法
初探富文本之OT協同實例
初探富文本之CRDT協同實例
實際上我們聊了很多文檔編輯器的內容，但是大都是本地實現的獨立的編輯器，涉及到多人協作的時候，獨立的編輯器就會出現問題，例如用戶A和B同時在寫文檔，很明顯在兩位同學進行保存的時候就會出現文檔覆蓋的問題，在這種情況下我們就需要文檔協同來調度。
當然協同的成本還是比較高的，如果成本不能接受的情況下使用悲觀鎖的方式也是可以接受的，顧名思義是基於一種以悲觀的態度類來防止一切數據衝突的方式，其以一種預防的姿態在修改數據之前把數據鎖住，然後再對數據進行讀寫，在其釋放鎖之前其他的任何人都不能對數據進行操作。
但是有個場景非常特殊，那就是劃詞評論的能力，設想一個場景，我們的在線文檔系統是由線上狀態和草稿狀態組成的，當然這也是常見的解決方案，此時我線上的文檔文本是xxxx，草稿被添加過文字了此時的狀態爲yyyyxxxx，如果此時用戶在線上的xxxx四個字也就是索引爲0-4上添加了評論，那麼此時在草稿的0-4爲yyyy，這樣的話添加評論的位置就產生了錯誤，導致下次發版本到線上之後評論的位置就錯了。
爲了解決上述的問題實際上就必須要引入協同算法來解決，協同本質上就是引入了合併與衝突的解決算法，所以在離線狀態引入協同算法來解決實際問題也是有很大價值的，是做在線文檔功能必不可少的一環能力。
所以我研究了大概得一個月的協同方案，並且又用了一個月的時間寫了上述的四篇文章，當時是在實習的過程中寫的，只能靠週末的時候學習，所以還是比較費勁的，尤其是我希望本着簡單的原則提供DEMO出來，這就更耗費了時間，所以這幾篇文檔真的是很有質量的內容。
流程圖編輯器
在之前看到了某個項目，其流程圖編輯器的UI跟我印象中很久之前用的ProcessOn特別像，然後我就比較好奇這件事，後來慢慢了解到ProcessOn可能是基於mxGraph實現的(現在可能是自研SVG+Canvas方案)，又因此重新看到了DrawIO這個項目，於是我就想既然ProcessOn能夠做出集成方案，那整體來說方案應該是可行的，於是開始調研這個項目。
因爲我的目標是純前端的NPM包的集成方案，在研究了一段時間後，我將整個項目遷移了過來，並且完成了 在線DEMO，並且將能力歸類整理出文章 基於drawio構建流程圖編輯器，並且在這裏我依然嘗試着將項目串聯起來，將流程圖編輯器這個項目作爲插件嵌入到了我的文檔編輯器 在線DEMO 當中。實際上實現整個嵌入功能的時候並不簡單，特別是將其作爲獨立的NPM包發佈的這部分，我提交了60+次來做項目的兼容與BUG處理，mxGraph是比較老的項目了，代碼都是純Js並且都是基於原型鏈的修改，或者我這麼說吧，即使是在我精簡之後，Graph.js 這一個文件的代碼就有10637行。
基於WebRTC的局域網文件
在前一段時間，我想在手機上向電腦發送文件，因爲要發送的文件比較多，所以我想直接通過USB連到電腦上傳輸，等我將手機連到電腦上之後，我發現手機竟然無法被電腦識別，能夠充電但是並不能傳文件，因爲我的電腦是Mac而手機是Android，所以無法識別設備這件事就變得合理了起來。那麼接着我想用WeChat去傳文件，但是一想到傳文件之後我還需要手動將文件刪掉否則會佔用我兩份手機存儲並且傳輸還很慢，我就又開始在網上尋找其他軟件，這時候我突然想起來了AirDrop也就是隔空投送，就想着有沒有類似的軟件可以用，然後我就找到了Snapdrop這個項目，我覺得這個項目很神奇，不需要登錄就可以在局域網內發現設備並且傳輸文件，於是在好奇心的驅使下我也學習了一下，並且基於WebRTC/WebSocket實現了類似的文件傳輸方案，並且在實現的過程中解決了如下問題:
- 局域網內可以互相發現，不需要手動輸入對方
IP地址等信息。 - 多個設備中的任意兩個設備之間可以相互傳輸文本消息與文件數據。
- 設備間的數據傳輸採用基於
WebRTC的P2P方案，無需服務器中轉數據。 - 跨局域網傳輸且
NAT穿越受限的情況下，基於WebSocket服務器中轉傳輸。
通過這種方式，任何擁有瀏覽器的設備都有傳輸數據的可能，不需要藉助數據線傳輸文件，也不會受限於Apple全家桶才能使用的隔空投送，並且在實現的過程中我還拓展了多文件發送、文本消息、嘗試公網連接等能力，總結起來通過這種方式我們可以獲得如下的收益：
- 天然的跨平臺優勢，常用的家庭PC或者移動設備通常都會擁有瀏覽器，所以我們可以輕鬆應用於常見的
IOS/Android/Mac設備向PC臺式設備傳輸文件的場景等等。 - 無視家庭路由器的
AP隔離功能，即使因爲各種原因比如合租時房東對路由器設備開啓了AP隔離，我們的服務依舊可以正常交換數據，這樣避免了在路由器不受我們控制的情況下通過WIFI傳輸文件的掣肘，但是這通常不適用於大型公司的對稱型NAT，至於原因我們後邊也會聊到。 - 公網的
P2P數據交換，在現在IPv6的普及下，如果設備支持IPv6並且擁有公網IPv6地址的話，是可以直接進行數據傳輸的，點對點的數據交換不會受限於服務器的數據轉發，並且隱私性會更高一些，當然因爲國內網絡環境的複雜性以及運營商對於UDP數據包的支持受限、IPv6地址只出不進等等限制，公網傳輸的實用性還是差一些的。
在耗費了兩個週末的時間之後，將整個功能完善了出來 仿照AirDrop(隔空投送)優雅地在局域網中傳輸文件，並且可以嘗試使用 在線DEMO，因爲本身數據不會經由服務器轉發，所以部署後大概佔用20MB左右的內存，使用效果可以查看README的 視頻。
基於Canvas的簡歷編輯器
掘金老給我推Canvas，於是我也學習Canvas做了個簡歷編輯器
Canvas圖形編輯器-數據結構與History(undo/redo)
Canvas圖形編輯器-我的剪貼板裏究竟有什麼數據
最開始本着學習的態度以及對技術的好奇心來做的，因爲暫時找不到可以用Canvas實現的比較有意思的場景，所以才選擇了繼續做簡歷編輯器 在線DEMO。因此除了一些工具類的包例如 ArcoDesign、ResizeObserve、Jest 等包之外，關於 數據結構packages/delta、插件化packages/plugin、核心模塊packages/core 等都是手動實現的，項目中的富文本內容還是用我的文檔編輯器實現的，又將項目串了起來，並且整個項目還是用Rspack打包的基準環境，前邊學習的Webpack又派上了用場幫我解決了一個打包問題。
實際上這也是本着 自己學習的項目能自己寫就自己寫，公司/商業化項目能有已有包就用已有包 的原則來的，在這裏的目標是學習而不是做產品，自己學習肯定是希望能夠更多地接觸相對底層一些的能力，自己可以多踩一些坑會對相關能力有更深的理解，如果是公司的項目那肯定是成熟的產品優先，成熟的產品對於邊界case的處理以及積攢的issue也不是輕易能夠比擬的。
此外，除了想學習的理由之外，針對於市面上簡歷編輯器本身的問題與痛點，也做了相關的解決方案：
- 固定模版不好用，各種模版用起來細節上並不是很滿意，要麼是模塊的位置固定，要麼是頁面邊距不滿意，而通過
Canvas實現的簡歷編輯器都是圖形，完全依靠畫布繪製圖形，在給定的基礎圖形上可以任意繪製，不會有排版問題。 - 數據安全不能保證，因爲簡歷上通常會存在很多個人信息，例如電話、郵箱等等，這些簡歷網站通常都需要登錄才能用，數據都存在服務端，雖然泄漏的可能性不大，但是保護隱私還是很重要的，此編輯器是純前端項目，數據全部存儲在本地，沒有任何服務器上傳行爲，可以完全保證數據安全。
- 維持一頁簡歷不易，之前使用某簡歷模版網站時，某一項寫的字較多時導出就會出現多頁的情況，而我們大家大概都聽說過簡歷最好是一頁，所以在實現此編輯器時是直接通過排版的方式生成
PDF，所以在設置頁面大小後，導出的PDF總會是保持一頁，看起來會更美觀。
雖然這只是一個小小的簡歷編輯器，但是針對編輯器涉及的能力還有很多，整體來看會涉及到很多技術問題，例如數據結構、History模塊、複製粘貼模塊、畫布分層、事件管理、無限畫布、按需繪製、性能優化、焦點控制、參考線、富文本、快捷鍵、層級控制、渲染順序、事件模擬、PDF排版等等，目前來說想要做好還是有很大難度的，也是一個可以深入研究的項目。
總結
感覺還是做了一些比較有意思的項目的，我個人覺得如果是搞技術的話，保持對技術的好奇心是一件很重要的事，能用技術來解決平時遇到的問題也是非常重要的一點，昨天聽羣友說他做了個項目用算法來下棋，面試官問他這個項目有什麼用，我覺得這就是個很有意思的項目，過年回家的時候跟大爺下棋能跟大爺下的有來有回可不是有用嗎，提供情緒價值也是很重要的。
再說回來我做的這些項目，最開始我的目的就非常簡單，我覺得這件事有意思我就去做了，並且在做的過程中不斷解決了很多問題，並且也不斷提升了技術水平，還能寫很多博客，何樂而不爲。其實在這裏我還思考過一個問題，什麼是好項目，這個問題就很寬泛，我覺得在這其中很重要的是將做過的項目聯繫起來，或者真的將其用到了自己的生活中，這對於自己來說就是好項目，或許對於面試來說這個項目的價值並不大，但是如果能對自己有所幫助，無論是生活上還是技術上，那就很重要。
還有一個問題我覺得也是值得討論的，內卷和努力的區別究竟是什麼，我目前的理解是內卷一定是有多個人一起在惡性的競爭，比如兩個人在比誰工作的時間長，誰加班加得多，這種就是純純的內卷，努力的話是一個人也可以做的事，當然多個人也可以，大家沒有利益衝突，相互學習相互幫助，一個人的話就是做着自己感興趣的事，比如每天下班後學習英語。但是話又說回來了，個人的努力實際上是在更大範圍上來說還是競爭，大家肯定也體會到整個環境越來越捲了，從另一個角度上講，這或許也是社會發展的動力所在吧。
那麼搞了這麼多項目，那麼我的朋友，代價是什麼呢？代價就是到現在都還沒有對象，過年回家差點就要去相親了，我很難繃。