?

?

數據采集是數據應用的源頭，指導企業在產品、運營和業務等多方面決策。本文作者王灼洲從數據采集需求出發，詳細解讀了如何實現高效、可用的數據采集方案。主要內容如下：

• 數據采集的定義和重要性

• 業內常見的數據采集方案

• 數據采集的原則

• 數據采集案例分析

一、數據采集的定義和重要性

所謂數據采集，即為了滿足數據統計、分析和挖掘的需要，搜集和獲取各種數據的過程。通常情況下，數據采集指的是采集企業內部的數據。

在當前互聯網領域，隨著流量紅利的衰退，越來越多的企業通過精細化運營，深度挖掘每一位用戶的價值。當下流行的數據驅動、精細化運營等方法論和實踐方式，也變得越來越重要，并且被越來越多的企業所接受和采納。而數據驅動、精細化運營都要基于數據來做各種決策。數據采集，正是它們的基礎和前提條件。

數據采集，本質上是為了數據應用。如果我們沒有任何數據上的應用需求，投入再大的精力，去做好數據采集其實也是沒有任何意義的。而數據應用，其實是一個比較大的范疇，包含最簡單的統計報表，復雜的交互式在線分析，當下非常熱門的個性化推薦等。

不管哪一類數據應用，都可以在大體上分成五個環節，如下圖：

在進行數據應用的時候，我們首先要通過各種方式采集數據；然后將采集得到的數據，通過實時或者批量的方式，向后進行傳輸；對于這些傳輸過來的數據，選擇合適的數據模型進行 ETL 和建模，并且根據后續的應用選擇合適的存儲方案；在數據完成建模并且存儲下來之后，就可以對數據進行統計、分析和挖掘等數據應用；而這些數據應用的結果，一方面，可以通過數據可視化的方式，直接展現，并幫助我們做出各種產品、運營和商業等方面的決策；另一方面，這些數據應用的結果，也可以直接反饋給產品，以類似于「猜你喜歡」的產品形態，直接作用在產品上。

很顯然，在一個典型的數據應用上，數據采集是第一個環節，是源頭，是一切數據應用的起點。如果數據采集沒有做好，影響了整體的數據質量，那么，在后面環節再想進行彌補，其代價會很大，效果也會大打折扣。最終的數據應用，以及基于應用得到的決策與反饋的質量也必然會受到影響。

從這個意義上來講，無論我們如何強調數據采集的重要性，也都不為過。

正是因為我們意識到了數據采集的重要性，神策數據的愿景隨之誕生，即“幫助中國三千萬企業重構數據根基，實現數字化經營”，希望通過我們的努力，能夠幫助我們的客戶和合作伙伴更好、更全面地采集數據，從而最大化地發揮數據的價值。也正是堅守于此，過去五年，不論是在數據采集技術，還是數據治理方案等方面，我們都做了很多的工作，也幫助了很多的客戶。比如我們建立強大的數據采集 SDK 研發團隊，并將 SDK 全部開源，也維護著近 1500 人的開源討論社群，同時不斷向業界輸出我們的積累、經驗和沉淀，讓數據采集技術不再神秘，更讓數據采集技術的生態更好、更健康的向前發展。

二、業內常見的數據采集方案

目前，市面上常見的埋點方式主要有三種：代碼埋點、全埋點和可視化埋點。

1.代碼埋點

所謂代碼埋點，即客戶端集成 SDK，在客戶端啟動的時候初始化 SDK，然后在某個事件（行為）發生時，客戶端顯示調用 SDK 的接口觸發相應的事件。

代碼埋點，是最常見的埋點方式，同時也是“最萬能”的埋點方式。

其優點如下：

（1）可以精準控制埋點；

（2）可以靈活添加自定義事件和屬性；

（3）可以滿足更精細化的分析需求。

同時，代碼埋點也有一些缺點：

（1）?前期埋點代價比較大；

（2）埋點的變更，需要伴隨客戶端的發版。

2.全埋點

全埋點，也叫無埋點、無碼埋點、無痕埋點、自動埋點等，是指無需開發工程師寫代碼或者只寫少量的代碼，就能預先自動采集用戶的所有行為數據，然后在數據分析產品上通過點選和配置，來篩選要分析和統計的對象。

全埋點優點如下：

（1）前期埋點成本相對較低；

（2）若分析需求或事件設計發生變化，無需應用程序修改埋點和發版；

（3）可以有效地解決“歷史數據回溯”問題。

同時，全埋點也有一些缺點：

（1）由于技術方面的原因，對于一些復雜的操作，比如縮放、滾動等，很難做到全面覆蓋；

（2）無法自動采集和業務相關的數據；

（3）無法滿足更精細化的分析需求；

（4）各種兼容性方面的問題；

（5）傳輸的數據量太大、浪費資源。

戳圖下載 iOS 全埋點技術白皮書

3.可視化埋點

所謂可視化埋點，即通過可視化的方式進行埋點。可視化埋點，一般需要依賴全埋點相關的技術。

可視化埋點一般有兩種表現方式：

一是默認情況下，不進行任何埋點，然后通過可視化的方式進行圈選，圈選哪些就采集哪些。

二是默認情況下，開啟全埋點全部采集，然后通過可視化的方式對全埋點的事件進行重命名。

比如，對于登錄頁面上的登錄按鈕，全埋點采集的事件名一般都是固定的，比如叫：$AppClick，借助于可視化埋點，我們就可以對 $AppClick 事件進行重命名，比如 login。

與代碼埋點和全埋點相比，可視化埋點看起來非常酷炫，但它也有相應的優缺點。?

優點：比如整個埋點比較貼近業務場景，同時也降低了埋點的技術門檻，運營人員、數據分析人員等非技術人員均可埋點。

缺點：由于可視化埋點是依賴于全埋點，因此他天然繼承了全埋點的缺點，比如兼容性問題、無法采集和業務相關的數據問題。

那么，埋點方案未來發展的趨勢是什么呢？

我理解，未來會逐步向場景化、行業化、智能化方向發展，比如如何通過可視化的方式，給事件添加動態屬性，類似于可視化動態屬性關聯。

三、數據采集的原則

面對這么多的數據采集方案，我們究竟該如何選擇呢？

神策這 5 年來，已累計服務 1500+ 家企業客戶，通過深度服務客戶，我們發現其實目前并沒有一種非常完美的埋點方案能夠適應所有的場景。不同的埋點方案，它們各有優缺點，都有他適應的場景和不適應的場景。面對這么多的埋點方案，不能一味追求省事，更不能追求埋點方式的「酷炫」，最主要的還是要根據實際的分析需求和業務場景，選擇最能滿足我們需求的埋點方式。若有多種埋點方案都能滿足，我們可以再追求「省事」和「酷炫」的方案。

比如對于上圖中的搜索頁面，我們的需求是，當用戶點擊搜索按鈕時，觸發一個事件，并將用戶輸入的關鍵詞作為事件屬性。

對于這個數據采集需求，若使用代碼埋點方案，操作和實現非常簡單；若使用全埋點方案，無法單獨完全滿足，這是因為全埋點雖然可以自動采集點擊搜索按鈕的點擊事件，但無法自動獲取關鍵詞并作為點擊事件的屬性，但也可以通過寫一定的代碼配合全埋點來滿足；如果使用可視化埋點的方案，如果我們能實現動態屬性關聯，也能實現上面的埋點需求。

因此，在數據采集領域，根本不存在什么銀彈，即不存在普適的完美方案能夠適合所有的應用場景。我們能夠做的，是針對不同的應用場景，選擇最合適的數據采集方案。

當然了，雖然沒有銀彈，但是數據采集中還是有一些比較通用的原則供我們參考，我們總結為四個字，即大、全、細、時。

大：充分考慮用戶規模與數據規模的增長，做好數據資產積累的準備。

全：多端采集，針對全量用戶行為而非抽樣，采集要貫穿用戶使用產品的整個生命周期。

細：盡可能采集足夠全面的屬性與維度，盡量保存數據細節，讓積累的數據資產更加優質。例如，從 Who、When、Where、How、What 這 5 個角度來采集用戶行為數據。

時：在技術條件與成本允許的情況下，盡可能地提高數據采集的時效性，從而提高后續數據應用的時效性。

四、數據采集案例分析

案例一：App 與 H5 打通

近年來，App ?的混合開發越來越流行，App 與 H5 的打通需求也越來越迫切。那什么是 App 與 H5 打通呢？所謂“打通”，是指 H5 集成 JavaScript 數據采集 SDK 后，H5 觸發的事件不直接同步給服務端，而是先發給 App 端的數據采集 SDK，經 App 端數據采集 SDK 二次加工處理后入本地緩存再進行同步。

App 為什么要與 H5 打通呢？主要是從以下幾個角度考慮。

1.數據丟失率

在業界，App 端采集數據的丟失率一般在 1% 左右，而 H5 采集數據的丟失率一般在 5% 左右（主要是因為緩存、網絡或切換頁面等原因）。因此，如果 App 與 H5 打通，H5 觸發的所有事件都可以先發給 App 端數據采集 SDK，經過 App 端二次加工處理后并入本地緩存，在符合特定策略之后再進行同步數據，即可把數據丟失率由 5% 降到 1% 左右。

2.數據準確性

眾所周知，H5 無法直接獲取設備相關的信息，只能通過解析 UserAgent 值獲取到有限的信息，而解析 UserAgent 值，至少會面臨如下兩個問題：

（1）有些信息通過解析 UserAgent 值根本獲取不到，比如應用程序的版本號等；

（2）有些信息通過解析 UserAgent 值可以獲取到，但內容可能不正確。

如果 App 與 H5 打通，由 App 端數據采集 SDK 補充這些信息，即可確保事件信息的準確性和完整性。

3.用戶標識?

如果用戶在 App 端注冊或登錄之前使用我們的產品，我們一般都是使用匿名 ID 來標識用戶。而 App 與 H5 標識匿名用戶的規則不一樣（iOS 一般使用 IDFA 或 IDFV，H5 一般使用 Cookie），進而就會導致一個用戶使用了我們的產品，結果產生了兩個匿名用戶的情況。如果 App 與 H5 打通，就可以將兩個匿名 ID 做歸一化處理（以 App 端匿名 ID 為準）。

那如何打通呢？在實現 App 與 H5 打通的過程中，神策數據經歷了三個階段，相對應地設計三個方案以應對不同時期的需求。

方案一：設想一個場景，你的 App 中嵌入了一個 H5，如果用戶啟動 App 但沒有進行注冊或登錄，這個時候該如何標識用戶？我們可能會用匿名 ID 或者設備 ID 進行標記，但是 H5 和 App 的匿名 ID 生成規則是不一樣的，H5 常用的是 Cookie；Android 常用的是 Android ID，或者最近比較流行的 OAID，或者 UUID；在 iOS 系統中，我們常用的是 IDFA，當 IDFA 被限制后，可以用 IDFV。因此，不管是 Android 還是 iOS，在跟 H5 進行混合的時候，用戶在產品上沒有注冊或的登錄的時候，會產生兩個匿名 ID，就相當于有兩個匿名用戶存在，這明顯與實際不符。

所以我們最初做數據打通時就面臨著戶標識的問題。在啟動內嵌入 H5 的時候，主動把 App 端生成的匿名 ID 傳給 H5，這樣 H5 產生的所有事件都可以用 App 傳來的匿名 ID 進行標識，完成用戶標識統一，這是 2016 年神策在處理 App 與 H5 打通的第一版解決方案。

方案二：為了解決數據準確性的問題，神策數據升級出第二版解決方案。

眾所周知，在瀏覽器查看網頁的時候，瀏覽器沒有辦法獲取到用戶的設備信息，就像用戶在電腦端打開網頁，網頁無法訪問用戶的磁盤，在手機端打開網頁，它也沒有辦法訪問用戶的相機、傳感器等，所以 H5 是如何獲取設備信息的呢？

一般情況下，H5 通過獲取當前 UA 值來做解析；但 UA 值的解析會存在很多問題，主要體現在 Web 和 Android 上，特別是 Android 系統中的很多瀏覽器，UA 值的規則無法統一，所以經常會遇到以下幾種情況：

（1）在數據采集的時候難以解析 UA 值；

（2）解析的數據非真實數據；

（3）對于 Android 和 iOS 來講，為了實現一些特殊功能，很多開發工程師會獲取修改 UA 值。有的工程師會在獲取之后進行追加，這是最好的方式；但也有工程師會在獲取后替換標準 UA 值，從而導致我們解析不到或者解析到的 UA 值不正確。

在 H5 中觸發的事件，通常需要采集其基礎屬性，如 App 版本號、當前操作系統版本號、操作系統的類型、屏幕尺寸等，此時單純通過 UA 值無法完成解析，就意味著對“打通”提出了更高要求。

基于此，神策把 H5 產生的事件通過一定的技術，傳給 App 集成的數據采集 SDK ，當 App 數據采集 SDK 接收到事件之后，對事件里的屬性內容進行二次加工，甚至是修正。一方面保證數據采集的準確性，另一方面保證數據的完整性。

因為神策客戶大多數采用私有化部署，神策難以統計用戶數據丟失率，但是在業界普遍標準是“App 的數據丟失率在 1% 左右，H5 和 Web 的數據丟失率在 5% 左右”，之所以有 5 倍差異，是因為 H5 的本地緩存是有限的，數據上傳失敗就意味著丟失；另外，大多情況下 H5 在 App 中以單頁面形式存在，H5 發送網絡請求之后，如果用戶退出頁面，其網絡請求隨之被取消，沒有辦法實現完全同步，這種情況下數據“打通”便朝著更高要求、高標準邁進——如何“打通”App 與 H5 降低數據丟失率？

App 采集的事件并非實時同步，因為 App 內事件多、頻率高，每次采集后立即同步會給服務器帶來很大的壓力，所以一般情況下，App 內會增加本地緩存，所有采集到的事件先存入本地緩存，達到一定條件后再進行同步。也就是說，根據緩存制定相應的數據同步策略。如果按照以上方案，將 H5 的事件傳給 App 進行二次加工，進入 App 端的本地緩存，走 App端事件同步策略，就能大大降低 H5 事件丟失的概率。

這是我們在 App 與 H5 打通的第二版中著重處理的內容，在該解決方案中，不管是用戶標識、數據準確性，還是數據完整性，都能得到解決。

方案三：第三版解決方案的問世是神策針對第二版方案持續完善、迭代的結果。

假設場景如下，某 App 內基層 H5 的開發者是第三方供應商。在這個情況下，會產生以下兩個問題：

（1）第三方供應商不是神策的客戶，沒法實現數據采集，更沒辦法完成“打通”；

（2）第三方供應商是神策的客戶，此時 App 與 H5 可以實現真正打通，但很多情況下會被迫收到很多不需要的數據，我們叫“臟數據”，而 H5 的供應商則會發現他們無法采集到完整數據，很多事件“莫名其妙”地丟了……這是因為 App 與 H5 打通后，H5 的事件默認傳給了 App。因此，在這種情況下，我們需要對更多的細節進行考慮，通過 H5 給 App 白名單的形式，實現 H5 的向 App 的事件上傳。

這個時候，我們就會面臨新的場景需求，第三方供應商答應把數據傳給 App，但是自己也要求保留一份。綜合來看，App 與 H5 的打通看起來是一個比較常見的場景，但在執行的過程中往往面臨較多挑戰。

從 2016 年到今天，面對 App 和 H5 的打通，我們一直在更新迭代中，目的是為了能夠適應各種復雜的場景，特別是涉及第三方開發框架、第三方瀏覽器等的“打通”。

戳圖了解《Android 全埋點解決方案》

案例二：App 啟動與退出

1.App 啟動?

什么叫“App 啟動”？有人說，使用 App 即“App 啟動”，那如果使用音樂播放器，播放器退出后臺音樂繼續播放，這樣可以算做“啟動”嗎？也有人說，用使用時長來定義“App 啟動”，那么在當用戶在“京東”有支付需求，跳轉到“微信”完成支付后又跳轉回“京東”內，可以計算為微信的“啟動”嗎？或者使用“微信”期間有騷擾電話來電，用戶立馬掛斷但中間仍持續了兩秒，在這兩秒的時間從“微信”跳轉到“來電”又轉回“微信”，算“啟動”嗎？

在前幾年，手機功能非常多，App、H5 等都是一座座孤島，隨著技術的發展，這些孤島在當前環境中相互之間建立了連接，實現了打通。那么，我們實現“App 啟動”也就會有很多方式：

第一，用戶點擊圖標完成 App 啟動，這是我們最常見的啟動方式。

第二，通過后臺喚醒，也即所謂的“熱啟動”。

第三，通過 H5 喚醒啟動，例如朋友通過微信給你分享了京東的商品，你點擊鏈接后一般情況下會在右上角提示“使用 App 打開”，如果你的手機里安裝了京東 App，那么就會實現京東 App 的啟動。

第四，通過一個 App 喚醒另外一個 App，比如地圖跳轉、支付跳轉、推送跳轉、小程序跳轉等。

明確了“App 啟動”的定義之后，如何采集 App 啟動就是接下來的重要工作，在這個過程中面臨如下挑戰：

挑戰一：是否首次啟動

首次啟動指的是用戶安裝 App 后的第一次啟動，這個場景通常叫做激活，通過一定的機制去判斷是否為首次啟動。有人說，可以在本地做標記來區分是否為首次啟動，但 Android 和 iOS 系統的設置都可以實現“清除本地緩存”的操作，難以通過本地標記來做區分；也有人說，可以通過 SD 卡完成標記，但讀寫 SD 卡需要權限，實際操作亦有難度。所以說，如何區分用戶是否為首次啟動存在著技術上的挑戰。

挑戰二：冷啟動和熱啟動

很多時候，我們會通過 Home 鍵讓 App 進入后臺，但由于時間過長或者系統資源等原因，App 可能會系統被回收，下一次啟動其實就變成了冷啟動，但是根據我們之前的定義，它實際上還是熱啟動。所以說，如何判斷冷啟動和熱啟動是一件非常復雜的事情。

挑戰三：是否從后臺恢復

常見從后臺恢復方式有兩種：①點擊圖標恢復；②雙擊 Home 鍵彈出應用列表，點擊應用列表完成恢復。所以說，采集方案能否覆蓋以上不同的恢復場景，對技術來說有一定的考驗，在數據分析過程中也需要去考慮復雜多變的場景。

挑戰四：iOS 被動啟動

這個內容很多人沒有接觸過，也不太了解，這是神策基于某些場景特定發明的。什么叫被動啟動？它是 iOS 系統內特有的，比如我們正在使用某個 App，由于一些其他原因將 App 轉入后臺，過了一定時間（iOS 官方文檔內稱作“特定時間”），系統會讓此 App 進入“僵尸狀態”，此時，App 后臺會給用戶進行推送。在 iOS 設備收到 App 的推送后，會對 App 進行初始化，從第一個頁面開始，這個過程對于用戶來說是透明的，按照全埋點的采集原理，初始化操作會觸發 App 啟動和頁面瀏覽事件，此種場景下的啟動我們稱之為“被動啟動”。

正是因此，我們在大概兩年多的時間里，經常聽到客戶抱怨，為什么采集的事件中很多用戶只有「啟動」和「頁面瀏覽」而沒有「退出」？這個問題在當時階段受技術限制，通常會被粗略判定為“刷量”。隨著場景越來越多，我們追求極致，深入探究，最終得以把這個問題搞明白。

但隨之而來的是，用戶不理解為什么神策采集到的日活數據（通常根據“啟動”來判斷）比其他工具采集到的量要低，這是因為我們把“正常啟動”和“被動啟動”做了區分。

這也是跟神策的價值觀息息相關，我們要在真實場景中采集真實數據，給企業帶來價值。

挑戰五：Android 多進程

多進程如何理解？我們常見的很多 App 會有“掃一掃”功能，這個時候必然會用到相機，在 Android 里會有很多 ROM，兼容性復雜，因此“掃一掃”頁面很容易崩潰；但是“掃一掃”在 App 中不一定是核心組件，即便它出現了問題，也不應該影響 App 的正常運行。所以一般情況下，會把“掃一掃”的業務邏輯或者頁面單獨設置一個進程，這樣“掃一掃”和主業務可以作為兩條獨立的、互不影響的進程并行存在。

在這個情況下，會對 Android 內的 App 啟動判斷帶來問題，因為無法判斷這兩個進程是否來自同一個 App。所以說，Android 和 iOS 的啟動的概念是不一樣的。

當用戶打開了一個頁面，與他打開該 App 上一個頁面的退出時間如果超過了 30 秒，我們就認為是 Android 內的一次“App 啟動”，這個叫“session 機制”；同樣，當用戶退出了一個頁面，30 秒內沒有打開新的頁面，就會被計算為一次“App 退出”。

挑戰六：合規

關于合規，大家了解的比較多，對于神策來說，因為我們的 SDK 是開源的，所以神策 SDK 的采集行為清晰可見，必然是合規的。

那么，合規會對啟動產生什么樣的影響呢？在數據采集的時候，必然要采集用戶的相關信息，比如設備 ID 等，這個時候，“合規”就會要求在數據采集之前必須經過用戶同意，也就是我們常見的 App 彈出的隱私政策說明等；另外，數據采集也會涉及到系統權限，只有用戶明確同意了，企業才能夠去做數據采集相關工作。

但是，以上流程是在用戶啟動 App 之后才完成的，這個時候就會錯過 App 啟動的數據采集時機，所以，為了達到合規，對于“App 啟動”的采集是有一定影響的。

2.App 退出?

大多數情況下，App 不顯示就算作一次退出，常見場景有：用戶點擊 Home 鍵；App 崩潰；App 跳轉等；但是對于音樂播放器、運動相關等的 App 來說，就需要對應地做一些特殊判斷。在采集“App 退出”的過程中，我們同樣會面臨挑戰：

挑戰一：App 退出原因

清晰了解用戶退出 App 的原因有助于對產品和業務開展分析。

挑戰二：App 使用時長

我們不僅要采集“App 退出”的動作，更要了解用戶使用 App 的時長。有人說，在“啟動”和“退出”分別記錄時間戳，通過計算得出 App 使用時長即可，但這個時間戳如何標記？

大多數情況下，我們會用客戶端時間來標記時間戳，但是如果用戶在“啟動”和“退出”之間，手動或者因為網絡原因，修改了手機設備時間又會怎樣？

通常會有以下幾種場景：“退出”減“啟動”等于 0 或接近 0；“啟動”的日期為 8 月 1 日，“退出”的日期為 8 月 30 日，使用時間過長，或者退出的日期被用戶手動調整為 7 月 30 日導致使用時間為負值等，這些情況明顯不符合實際。因此，采集 App 使用時長不能純粹依靠設備時間。

那么，神策是如何應對該挑戰的呢？在 Android 和 iOS 兩個操作系統中，都有一個特殊功能叫“計數器“，就是說在你的操作系統開機的時候，計數器從 0 開始計數，這也是我們從手機“設置”里能看到的手機開機時長，因此，用這個時間來計算用戶的 App 使用時長，得到的數據 100% 是正確的。

挑戰三：退出事件補發

前些年有人提出這個場景：假如用戶的手機掉水里了，神策能否采集到退出事件？我的回答是，如果用戶的手機能從水里拿出來，能正常開機并正常啟動 App，那么就可以實現退出事件補發。

什么叫補發？因為用戶在使用 App 的時候，可能會隨時退出，針對此，我們在用戶啟動頁面的時候，完成計數，每隔一定時間記錄一次，如果在用戶下一次啟動 App 的時候，我們發現這個時間戳還在，但是沒有觸發啟動事件，那么我們就會立即把上一次的退出事件補發。

不管是“啟動”還是“退出”，都是我們在實際數據采集與業務分析時的常見場景。神策面對客戶的每一個場景、每一個挑戰都能迎難而上，這是秉承對客戶負責的責任感，更是神策追求極致的表現。

作者介紹

王灼洲先生是《Android 全埋點解決方案》《iOS 全埋點解決方案》作者，神策數據治理研發部負責人。有 10+ 年 Android & iOS 相關開發經驗，是國內第一批從事 Android 研發工作，開發和維護國內第一個商用的開源 Android & iOS 數據埋點 SDK。

王灼洲先生曾就職于北京天宇朗通通信設備股份有限公司，擔任 Android 系統工程師。畢業于北京理工大學，軟件工程專業。

本期分享分為「數據采集」和「數據治理」上下兩篇，以上僅涉及數據采集相關內容。“數據治理的方案解讀和落地實踐”即將推出，敬請期待！

???

【相關閱讀】

• 我在神策做研發丨 幸好優秀無聲，否則震耳欲聾

• 簽約丨老鄉雞攜手神策數據，共同推動餐飲數字化創新

• 神策數據潘書薈：解讀千人千面，洞悉數據智能的價值

?

總結

以上是生活随笔為你收集整理的神策数据王灼洲：方法论 + 实践，全面解析数据采集方案，必看！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。