摘要：當(dāng)然，這只是結(jié)合自己項(xiàng)目的工程結(jié)構(gòu)和特點(diǎn)設(shè)置的一套使用方式，僅供參考開發(fā)富文本編輯器的教訓(xùn)由于項(xiàng)目的時(shí)間較緊張，我在頁面上應(yīng)用了框架的背景下，想當(dāng)然的想要把也應(yīng)用于富文本編輯器的開發(fā)，事實(shí)證明這是不太可行的。

此文已由作者劉詩川授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn)。

最近我們的產(chǎn)品有一個(gè)需求是要在PC端做一個(gè)面向用戶的書評(píng)編輯器，讓用戶和編輯在蝸牛讀書上能方便快捷的編輯和產(chǎn)出一些優(yōu)質(zhì)的文章，它的主要難點(diǎn)就是富文本編輯器部分。

這雖然是個(gè)業(yè)務(wù)需求，但是做業(yè)務(wù)的同時(shí)也要兼顧技術(shù)，所以在跟需求商量好不支持IE8之后，決定采用Vue來作為前端部分的技術(shù)架構(gòu)。

前端架構(gòu)
webpack配置
Vue是一個(gè)非常優(yōu)秀的前端MVVM框架，輕量、快速、文檔友好又詳細(xì)，代碼組織也非常優(yōu)雅，是我比較偏愛的MVVM架構(gòu)。Vue官方提供了非常方便快速上手的腳手架Vue-cli，但是由于跟我們這邊使用的Java Web架構(gòu)有一些不太適合的地方，所以我并沒有使用它，不過我也是對(duì)Vue-cli做了一番詳細(xì)的學(xué)習(xí)后來搭建自己的webpack配置。

下面是我的生產(chǎn)環(huán)境的部分webpack配置，其實(shí)并不復(fù)雜，因?yàn)槲业臉I(yè)務(wù)場(chǎng)景也并不復(fù)雜，現(xiàn)在的各種插件功能也足夠強(qiáng)大。

webpack.prod.config.js

devtool: "source-map", plugins: [ new CleanWebpackPlugin(["dist"]), new ExtractTextPlugin("[name].css"), new webpack.DefinePlugin({ "process.env": { NODE_ENV: ""production"" } }), new webpack.optimize.CommonsChunkPlugin({ name: "vendor", minChunks: function(module, count) { return ( module.resource && /.js$/.test(module.resource) && module.resource.indexOf("node_modules") >= 0 ) } }), new webpack.optimize.CommonsChunkPlugin({ name: "manifest", filename: "manifest.js", chunks: ["vendor"] }), new webpack.optimize.UglifyJsPlugin({ sourceMap: true, compress: { warnings: false } }), ]
主要就是借鑒了Vue-cli中的code split思路，開發(fā)環(huán)境的webpack配置區(qū)別不大，只是sourcmap設(shè)置改為了devtool: "#cheap-module-eval-source-map",去掉了代碼壓縮等。

需要注意的一點(diǎn)是，我在生成環(huán)境下的webpack配置中使用了vue-loader附帶的postcss預(yù)處理器中的cssnano插件進(jìn)行css部分的代碼壓縮，但是這個(gè)插件打包時(shí)會(huì)將z-index:10壓縮成z-index:1，需要添加設(shè)置zindex: false才能避免這個(gè)問題,而且cssnano插件默認(rèn)還有一個(gè)特性就是會(huì)刪除沒有使用到的css部分，比如我們?yōu)镃SS3動(dòng)畫所需構(gòu)建的keyframes，居然也會(huì)被cssnano認(rèn)為是沒有被使用的css，壓縮過程中也刪掉了，這個(gè)就有點(diǎn)費(fèi)解了，所以為了避免這種情況，我們需要增加設(shè)置discardUnused: false：

webpack.prod.config.js

rules: [{ test: /.vue$/, loader: "vue-loader", options: { loaders: { css: ExtractTextPlugin.extract({ use: "css-loader", fallback: "vue-style-loader" }), scss: ExtractTextPlugin.extract({ use: ["css-loader","sass-loader"], fallback: "vue-style-loader" }) }, postcss: [ require("autoprefixer")({ browsers: ["> 1%"] }), require("cssnano")({ zindex: false, discardUnused: false }) ], } }]

與Java Web的結(jié)合
為了將css文件抽離出來，我在開發(fā)環(huán)境也沒有使用Hot Module Reload機(jī)制(使用了ExtractTextPlugin抽離css文件后，修改css樣式不能通過HMR自動(dòng)更新，需手動(dòng)刷新)。

我們部門這邊的Java Web除了一些簡(jiǎn)單的靜態(tài)活動(dòng)頁，主要頁面的承載頁都會(huì)配置在另外的一個(gè)存放freeMarker的ftl文件的文件夾中，有別于靜態(tài)文件的存放位置，這是部門中的Java Web一直沿用的文件結(jié)構(gòu)，不好也沒太大必要去改變它。

這就使得Vue-cli或者一些常見的webpack配置中的根據(jù)文件hash生成打包文件再使用html-webpack-plugin自動(dòng)注入承載頁的功能不太好實(shí)現(xiàn)，所以就需要結(jié)合部門自己的情況定制比較符合自己項(xiàng)目的打包流程。

我們有個(gè)網(wǎng)站應(yīng)用自動(dòng)部署平臺(tái)，它的功能除了解析和編譯后端工程代碼，還會(huì)自動(dòng)分析頁面引用的靜態(tài)資源，然后將資源的URL替換為對(duì)應(yīng)的CDN域名的下的資源鏈接并添加資源MD5值相關(guān)的查詢值后綴，比如/static/js/app.js會(huì)在自動(dòng)部署后變成//yuedust.yuedu.126.net/snail_st/static/js/app.js?a63ed8a8。

所以既然目前項(xiàng)目中已經(jīng)有了CDN域名替換和文件hash計(jì)算的功能，我在webpack打包中就沒必要再多此一舉了，而且，我還可以利用這一特性，固定的設(shè)置承載頁引用的靜態(tài)資源的URL，部分代碼如下：

index.ftl

這樣設(shè)置好后無論本地開發(fā)還是部署線上都不需要再修改ftl文件的內(nèi)容了，既有效的利用到了Code Split加快打包速度和緩存利用率高的優(yōu)點(diǎn)，也使得開發(fā)和部署變得簡(jiǎn)單，頁面引用的靜態(tài)資源一旦添加，就不需要再去更改路徑了。

當(dāng)然，這只是結(jié)合自己項(xiàng)目的Java Web工程結(jié)構(gòu)和特點(diǎn)設(shè)置的一套webpack使用方式，僅供參考

開發(fā)富文本編輯器的教訓(xùn)
由于項(xiàng)目的時(shí)間較緊張，我在頁面上應(yīng)用了Vue框架的背景下，想當(dāng)然的想要把Vue也應(yīng)用于富文本編輯器的開發(fā)，事實(shí)證明這是不太可行的。

富文本中的數(shù)據(jù)渲染
Vue是數(shù)據(jù)和展現(xiàn)雙向綁定的，這使得特定格式的數(shù)據(jù)渲染成對(duì)應(yīng)的html非常的方便。

但是網(wǎng)頁上的富文本編輯器普遍都是利用的是元素的contenteditable屬性，這個(gè)屬性是無法實(shí)現(xiàn)雙向綁定的，要想實(shí)時(shí)保存富文本數(shù)據(jù)，只能監(jiān)控元素的輸入事件，然后讀取元素的innerText后再去修改數(shù)據(jù)，但是一旦修改了數(shù)據(jù)，就會(huì)觸發(fā)Vue的視圖更新，導(dǎo)致你編輯元素的innerText被重新渲染，元素一旦被重新渲染，用戶輸入時(shí)的獲取的光標(biāo)焦點(diǎn)就消失了，而且在windows和mac os下的輸入法實(shí)現(xiàn)有些不一樣,mac下的輸入法輸入中文會(huì)先將用戶輸入的拼寫填充到輸入元素中，導(dǎo)致獲取的innerText不準(zhǔn)確，所以想要利用Vue的數(shù)據(jù)雙向綁定機(jī)制來開發(fā)富文本部分，又想要實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)保存，存在很多問題。

富文本中的不可編輯區(qū)域
我們的書評(píng)內(nèi)容的數(shù)據(jù)結(jié)構(gòu)是一個(gè)各種item類型組成數(shù)組，item的類型有：文字、圖片、書籍和筆記，富文本編輯器需要將這些數(shù)據(jù)展現(xiàn)出來并且可編輯，其中書籍和筆記的數(shù)據(jù)結(jié)構(gòu)只能添加或者刪除，而不能修改，這就與傳統(tǒng)的富文本編輯器存在一定的區(qū)別，即富文本編輯器區(qū)域需要插入或者刪除不能修改的元素。這個(gè)需求使得一個(gè)普通的富文本編輯器變得特殊起來，一開始我的思路是在contenteditable="true"的編輯器主體內(nèi)插入contenteditable="false"的dom結(jié)構(gòu)，這導(dǎo)致插入部分的文本無法與編輯器很好的交互，包括刪除、撤銷、選中等，最后找到了另外一種比較理想的解決辦法。

開發(fā)富文本編輯器的一些經(jīng)驗(yàn)
以下是我在開發(fā)一個(gè)本業(yè)務(wù)場(chǎng)景下的富文本編輯器的一些經(jīng)驗(yàn)：

在開源富文本編輯器的基礎(chǔ)上開發(fā)
知乎上有個(gè)問題，叫做為什么都說富文本編輯器是天坑？，里面提到的很多開發(fā)富文本編輯器會(huì)遇到的一些難點(diǎn)，而我的第一版也是想著自己從頭開始開發(fā)，但是的確碰到了很多沒想到的問題，修修補(bǔ)補(bǔ)最終結(jié)果還是不滿意。

所以如果是需要一個(gè)常規(guī)功能的富文本編輯器，盡量選擇成熟穩(wěn)定的開源項(xiàng)目，保證穩(wěn)定可靠，如果需要像我一樣開發(fā)一個(gè)符合特定業(yè)務(wù)場(chǎng)景的富文本編輯器，也盡量在開源項(xiàng)目的基礎(chǔ)上進(jìn)行二次開發(fā)，這樣雖然會(huì)有一些代碼冗余，但是能幫助你避開許多前人已經(jīng)踩過的坑，而且也能從閱讀這些項(xiàng)目的源碼中學(xué)習(xí)到不少忽視的知識(shí)和特性。

我選擇的是國(guó)內(nèi)的一個(gè)個(gè)人開發(fā)者維護(hù)的叫做wangEditor的項(xiàng)目，它比較輕量，源碼也比較清晰便于二次開發(fā)。

基于DOM的數(shù)據(jù)渲染
要想在WEB端實(shí)現(xiàn)富文本編輯，經(jīng)過我踩的一些坑，我覺得最終還是要回歸于DOM的，Vue或者其他MVVM框架確實(shí)給開發(fā)和維護(hù)帶來很大的遍歷，但是在富文本編輯這塊，還是沒有DOM API來的可控。我的方案是根據(jù)服務(wù)端提供的一篇書評(píng)的items，組織出相應(yīng)的HTML，然后再交給富文本編輯器進(jìn)行初始化。

基于瀏覽器的document.execCommand API進(jìn)行開發(fā)
當(dāng)一個(gè)HTML文檔處于設(shè)計(jì)模式(designMode)或者一個(gè)HTML元素設(shè)置了contentEditable="true"時(shí)，我們可以使用execCommand方法，運(yùn)行一些命令來操縱可編輯區(qū)域的內(nèi)容，這個(gè)API可以快速可靠的對(duì)富文本區(qū)域的選區(qū)內(nèi)容進(jìn)行一系列的操作，最關(guān)鍵是，支持撤銷和重做功能，并且在撤銷和重做的過程中能夠完美的保持選區(qū)的狀態(tài)，這一點(diǎn)非常重要，我們可以通過保存html來實(shí)現(xiàn)內(nèi)容的撤銷和重做，但是選區(qū)或者說光標(biāo)的撤銷和重做，用Javascript很難完美的控制,如果只是保存之前選區(qū)的range對(duì)象，是不能復(fù)原選區(qū)或者光標(biāo)的。

具體支持的API可以參考MDN的文檔。

即使對(duì)于一些文檔中不支持的API，也建議通過以上API來組合實(shí)現(xiàn)，比如一段HTML內(nèi)容的替換，應(yīng)該先通過Javascript建立相應(yīng)的選區(qū)，然后運(yùn)行delete命令刪除該段內(nèi)容，再通過insertHTML來插入所需的HTML，這樣才能充分的利用瀏覽器的撤銷和重做功能，并且與其他的操作串聯(lián)起來。

富文本中的換行
富文本編輯器中的換行是一個(gè)值得注意的問題，我在開發(fā)書評(píng)編輯器的時(shí)候，遇到了一些問題：

富文本中展示換行看起來很容易，有幾個(gè)方案，比如設(shè)置CSS的white-space再配合換行符，或者在DOM中添加
元素，看起來都能達(dá)到目的。但是書評(píng)編輯器特殊的地方在于，這是一個(gè)已經(jīng)制定好了數(shù)據(jù)結(jié)構(gòu)并且在客戶端上也有編輯器，這就涉及到Web、iOS、Andorid三個(gè)端的一致性問題。

因?yàn)樵诳蛻舳松鲜菦]有
概念的,客戶端編輯器上需要換行位置插入的都是回車符，也就是n，而這些換行符在WEB上如果需要顯示成換行，就需要設(shè)置white-space為pre或者pre-line

如果設(shè)置為white-space: pre;，確實(shí)可以原樣顯示文本換行，但是如果是這樣一條數(shù)據(jù)：

這是書評(píng)中的一條文本數(shù)據(jù)，其中有兩個(gè)換行符，代表要展示成三行，其中有一個(gè)空行，實(shí)際需要展示的效果是下圖這樣的：

這樣的數(shù)據(jù)如果要展示在一個(gè)DOM節(jié)點(diǎn)中，設(shè)置為white-space: pre;,換行雖然保留了，但是由于第一行數(shù)據(jù)是連續(xù)的，white-space: pre;原樣保持了數(shù)據(jù)的換行，導(dǎo)致了第一行超出了DOM的最大寬度，這樣的方式顯然就行不通了。

如果設(shè)置成white-space: pre-line，pre-line可以在正確顯示換行符的同時(shí)讓超出一行的文字自動(dòng)換到下一行，看起來很完美。但是，一旦在換行符之后（比如中間空的那行）輸入文字，問題又出現(xiàn)了，在white-space: pre-line的元素中，如果在換行符之后輸入文字，換行符會(huì)被刪除，文字將會(huì)跳動(dòng)到上一行繼續(xù)顯示，這樣顯然是不行的。

最終的方案只有剩插入
元素來實(shí)現(xiàn)換行了，通過
實(shí)現(xiàn)的換行，不會(huì)出現(xiàn)輸入文字換行失效的問題，也不需要父元素設(shè)置white-space: pre;，所以我們需要將客戶端在文本中插入的n轉(zhuǎn)換成
，最后把HTML結(jié)構(gòu)重新解析成書評(píng)數(shù)據(jù)的時(shí)候，又需要將它們轉(zhuǎn)換回來以便保證客戶端編輯和展示的一致性，當(dāng)然這中間還有一系列的轉(zhuǎn)換邏輯,包括針對(duì)客戶端老版本的編輯器的一些BUG做的兼容，最后為了實(shí)現(xiàn)一致還是廢了一番功夫的。

富文本中的不可編輯區(qū)域
如上面兩圖，我們的書評(píng)中有一部分內(nèi)容是用戶引用的某一本書籍、或是用戶在閱讀時(shí)記錄的書籍原文，這些數(shù)據(jù)結(jié)構(gòu)都是不能被修改的，只能插入或者刪除，一開始我的思路是把該部分DOM結(jié)構(gòu)設(shè)置為contenteditable="false",但是這樣的設(shè)置代碼上不管怎么去彌補(bǔ)體驗(yàn)上都不夠好。

后來我轉(zhuǎn)變了思路，既然這就是一段不可編輯只能觀看的DOM，而富文本編輯器里插入的圖片是能夠很好的與文字一起被很好的操作和維護(hù)的，那么為什么不把不可編輯的展示區(qū)域直接轉(zhuǎn)換為圖片插入到富文本區(qū)域呢，事實(shí)證明這個(gè)思路最后的體驗(yàn)非常好，除了一個(gè)小的技術(shù)問題，下面一點(diǎn)會(huì)說明。

將DOM轉(zhuǎn)換為圖片
要將一個(gè)DOM轉(zhuǎn)化為圖片，社區(qū)里已經(jīng)有不少很成熟的開源庫可以使用，比如我使用的是dom-to-image，需要注意的就是一個(gè)問題：DOM轉(zhuǎn)化為圖片，基本都利用到了canvas的toDataUrl()功能將圖片轉(zhuǎn)化轉(zhuǎn)化為base64編碼的URL，這里面有一個(gè)安全策略，就是如果canvas中繪制的DOM結(jié)構(gòu)中有圖片，而該圖片與當(dāng)前頁面的域名不一樣（這在我們的開發(fā)場(chǎng)景中很常見），出于安全策略的限制，此時(shí)瀏覽器是不允許調(diào)用canvas的toDataUrl()方法的，而我們的書籍卡片中必定會(huì)有書籍的封面，該封面的域名是我們的CDN域名，所以轉(zhuǎn)換成圖片被限制了。

要想解決這個(gè)辦法，就涉及到一個(gè)前端的IMG標(biāo)簽的屬性：crossOrigin,如果將這個(gè)屬性設(shè)置為anonymous,瀏覽器就會(huì)為這張圖片的請(qǐng)求的Request Headers 中附帶Origin為當(dāng)前域名的這一行信息，告訴圖片所在的靜態(tài)資源服務(wù)器，這張圖片我需要跨域訪問以及我的域名，請(qǐng)?jiān)趫D片的Response Headers中附加Access-Control-Allow-Methods和Access-Control-Allow-Origin這兩行信息,如下圖：

這樣請(qǐng)求得到的圖片渲染到canvas中，瀏覽器才不會(huì)限制該canvas轉(zhuǎn)化為base64的URL。

這一特性需要服務(wù)端的支持，有的服務(wù)端就算附加了這個(gè)Request Headers字段依然不會(huì)返回想要的Response。

但是在支持這一特性的服務(wù)端，有時(shí)候設(shè)置了crossOrigin="anonymous"依然顯示這個(gè)錯(cuò)誤，不是這個(gè)屬性沒生效，而是我們的圖片一般是存放在CDN上的，而CDN為了更快的返回用戶的請(qǐng)求，會(huì)把圖片的響應(yīng)緩存下來，而這些緩存下來的響應(yīng)顯然是沒有Access-Control-Allow-Methods和Access-Control-Allow-Origin這兩行信息的，所以這時(shí)候即使我們認(rèn)為自己的請(qǐng)求包含了crossOrigin="anonymous"，CDN服務(wù)器不認(rèn)為這是一個(gè)不同的請(qǐng)求，所以返回給我們的響應(yīng)是之前就緩存好的，導(dǎo)致了這個(gè)問題的發(fā)生。

這種情況就需要我們?yōu)槲覀冋?qǐng)求的圖片URL后添加一個(gè)時(shí)間戳來避免CDN服務(wù)器的緩存。

避免使用CDN來提高渲染速度
前端開發(fā)中說到提高頁面的加載速度，一般都會(huì)提到最大限度的利用CDN緩存靜態(tài)資源，以提高靜態(tài)資源的訪問速度，從而更快的將網(wǎng)頁內(nèi)容呈現(xiàn)給用戶。

但是，我上面提到的將含有跨域CDN圖片的DOM節(jié)點(diǎn)渲染成圖片的情況下，向CDN代理節(jié)點(diǎn)請(qǐng)求圖片資源反而會(huì)比我們直接向靜態(tài)資源源站點(diǎn)請(qǐng)求要來的慢，其實(shí)這也很好理解：

為了將含有跨域CDN圖片的DOM利用HTML5``canvasAPI渲染成圖片，我們就需要為該圖片的添加crossOrigin="anonymous"屬性，并且為圖片的請(qǐng)求URL添加一個(gè)時(shí)間戳

如果我們?cè)L問的是CDN域名下的圖片，同時(shí)又為URL添加了一個(gè)全新的時(shí)間戳，那么這個(gè)圖片資源的請(qǐng)求對(duì)于CDN代理節(jié)點(diǎn)來說肯定是全新的，也就是會(huì)認(rèn)為本節(jié)點(diǎn)上沒有這個(gè)資源的緩存

CDN代理節(jié)點(diǎn)遇到一個(gè)自己沒有緩存的資源，它就會(huì)向靜態(tài)資源的源站點(diǎn)去請(qǐng)求，得到結(jié)果后再轉(zhuǎn)發(fā)給用戶，這等于說我們這個(gè)帶有時(shí)間戳的圖片URL的請(qǐng)求，不但沒能利用的CDN的緩存提速，反而由CDN代理節(jié)點(diǎn)充當(dāng)了一次中介，這顯然會(huì)增加資源的返回耗時(shí)

上面兩圖分別就是請(qǐng)求CDN域名圖片的耗時(shí)和請(qǐng)求源站點(diǎn)圖片的耗時(shí)，經(jīng)過多次測(cè)試，可以發(fā)現(xiàn)請(qǐng)求CDN域名圖片的耗時(shí)基本在200ms以上，而向源站點(diǎn)的請(qǐng)求基本都在100ms以下，所以，有的時(shí)候，比如這種特殊情況下，請(qǐng)求CDN域名下的資源可能反而會(huì)增加請(qǐng)求的耗時(shí)。

Promise大法好
根據(jù)上面提到的流程，需要我把從服務(wù)端拿到的一個(gè)包含各種類型item的數(shù)組解析成一個(gè)HTML字符串，其中包含了書籍和筆記類型的item需要轉(zhuǎn)化成的base64格式的圖片，這就出現(xiàn)了時(shí)序上的問題：

文本和圖片類型的item，可以直接得到對(duì)應(yīng)的HTML字符串，而書籍和筆記類型的item，則需要通過網(wǎng)絡(luò)請(qǐng)求和canvas轉(zhuǎn)換，但是最終我又需要得到整個(gè)的初始HTML內(nèi)容來初始化富文本編輯器，然后再讓用戶可以去在這些HTML DOM節(jié)點(diǎn)上進(jìn)行編輯，這就需要用到Promise.all這個(gè)API了，代碼示例如下：

App.vue

/* 將服務(wù)端返回的書評(píng)items轉(zhuǎn)換為html string傳輸給富文本編輯器 @param {json array} items 書評(píng)items @return {promise} 所有items處理好后返回resolve(htmlStr), 否則reject(error) */ convertItemsToHtml(items){ return new Promise ( (resolve, reject) => { let htmlStr = ""; let itemStr = ""; let itemPromises = items.map( item => { return new Promise( (resolve, reject) => { switch(item.resourceType){ case "Text": itemStr =

"Text">${item.text}

; resolve(itemStr); break; ... case "BookNote": let $BookNoteEle = $(

${item.bookNote.markText}

).appendTo($("body")); domtoimage.toPng($BookNoteEle[0], {style: {opacity: 1, zIndex: 1}}) .then(function (dataUrl) { itemStr =

"BookNote">"BookNote" >"${escape(JSON.stringify(item))}" src="${dataUrl}">

; $BookNoteEle.remove(); resolve(itemStr); }) .catch(function (error) { console.error("圖片生成失敗", error); reject(error); }); break; } }) }) Promise.all(itemPromises).then( ([...itemStrs]) => { htmlStr = itemStrs.reduce( (acc, val) => { return acc + val }, ""); resolve(htmlStr); }).catch( (error) => { reject(error); }) }) },
利用Promise.all和其他一些ES6的特性，可以使我們的代碼變得更加強(qiáng)大而簡(jiǎn)潔。

以上就是我在開發(fā)特定業(yè)務(wù)需求的富文本編輯器中遇到的一些問題和總結(jié)的一些經(jīng)驗(yàn)，可能會(huì)有一些錯(cuò)誤，希望幫忙指正。 其他一些常見的富文本編輯中會(huì)遇到的問題，可以通過學(xué)習(xí)一些開源的成熟富文本編輯器項(xiàng)目來得到解答。

免費(fèi)領(lǐng)取驗(yàn)證碼、內(nèi)容安全、短信發(fā)送、直播點(diǎn)播體驗(yàn)包及云服務(wù)器等套餐

更多網(wǎng)易技術(shù)、產(chǎn)品、運(yùn)營(yíng)經(jīng)驗(yàn)分享請(qǐng)點(diǎn)擊。

文章來源： 網(wǎng)易云社區(qū)