如何優(yōu)化PHP和Laravel以提高Web應(yīng)用的性能

這篇文章主要講解了“如何優(yōu)化PHP和Laravel以提高Web應(yīng)用的性能”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“如何優(yōu)化PHP和Laravel以提高Web應(yīng)用的性能”吧！

我們提供的服務(wù)有：網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、西陵ssl等。為1000多家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢(xún)和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的西陵網(wǎng)站制作公司

四種類(lèi)型的優(yōu)化

在我看來(lái)，優(yōu)化可以在四個(gè)不同的層面上進(jìn)行（當(dāng)涉及到PHP應(yīng)用時(shí)，就是）：

語(yǔ)言層面：這意味著你使用更快的語(yǔ)言版本，并避免語(yǔ)言中特定的功能/編碼風(fēng)格，使你的代碼速度變慢。
框架層面：這些是我們?cè)诒疚闹幸婕暗膬?nèi)容。
基礎(chǔ)設(shè)施層面：調(diào)整你的 PHP 進(jìn)程管理器、Web 服務(wù)器、數(shù)據(jù)庫(kù)等。
硬件層面：轉(zhuǎn)向更好、更快、更強(qiáng)大的硬件主機(jī)提供商。

所有這些類(lèi)型的優(yōu)化都有其存在的意義（例如，php-fpm 的優(yōu)化是非常關(guān)鍵和強(qiáng)大的）。但本文的重點(diǎn)是純粹的第 2 類(lèi)優(yōu)化：那些與框架相關(guān)的優(yōu)化。

要注意 n+1 數(shù)據(jù)庫(kù)查詢(xún)

n+1 查詢(xún)問(wèn)題是使用 ORM 時(shí)常見(jiàn)的問(wèn)題。Laravel 有其強(qiáng)大的 ORM，叫 Eloquent，它是如此的漂亮，如此的方便，以至于我們常常忘記了看是怎么回事。

考慮一個(gè)非常常見(jiàn)的場(chǎng)景：顯示指定客戶(hù)列表下的所有訂單。這在電子商務(wù)系統(tǒng)和任何需要顯示與某些實(shí)體相關(guān)的所有實(shí)體的列表中非常常見(jiàn)，

我們可以想象有這樣一個(gè)控制器：

class OrdersController extends Controller
{
    // ...

    public function getAllByCustomers(Request $request, array $ids) {
        $customers = Customer::findMany($ids);
        $orders = collect(); // new collection

        foreach ($customers as $customer) {
            $orders = $orders->merge($customer->orders);
        }

        return view('admin.reports.orders', ['orders' => $orders]);
    }
}

太好了！更重要的是，優(yōu)雅，美麗。??

不幸的是，用 Laravel 編寫(xiě)這樣的代碼是一種災(zāi)難性的方法。

原因如下。

當(dāng)我們使用 ORM 查找給定的客戶(hù)實(shí)體時(shí)，會(huì)生成這樣一個(gè)SQL查詢(xún)語(yǔ)句：

SELECT * FROM customers WHERE id IN (22, 45, 34, . . .);

這與預(yù)期的完全一致。結(jié)果，所有返回的行都被存儲(chǔ)在控制器函數(shù)中的集合 $customers 中。

現(xiàn)在我們逐一循環(huán)處理每個(gè)客戶(hù)，并獲取他們的訂單。這將執(zhí)行下面的查詢(xún)……

SELECT * FROM orders WHERE customer_id = 22;

……有多少客戶(hù)就有多少次。

換句話(huà)說(shuō)，如果我們需要獲取 1000 個(gè)客戶(hù)的訂單數(shù)據(jù)，那么執(zhí)行的數(shù)據(jù)庫(kù)查詢(xún)總數(shù)將是1（用于獲取所有客戶(hù)的數(shù)據(jù)）+1000（用于獲取每個(gè)客戶(hù)的訂單數(shù)據(jù)）=1001。這就是 n+1 這個(gè)名字的由來(lái)。

我們可以做得更好嗎? 當(dāng)然可以！通過(guò)使用預(yù)加載，我們可以強(qiáng)制 ORM 執(zhí)行 JOIN，并在一次查詢(xún)中返回所有需要的數(shù)據(jù)！就像這樣：

$orders = Customer::findMany($ids)->with('orders')->get();

由此產(chǎn)生的數(shù)據(jù)結(jié)構(gòu)是一個(gè)嵌套結(jié)構(gòu)，當(dāng)然，但訂單數(shù)據(jù)可以很容易地提取出來(lái)。在這種情況下，產(chǎn)生的單個(gè)查詢(xún)是這樣的。

SELECT * FROM customers INNER JOIN orders ON customers.id = orders.customer_id WHERE customers.id IN (22, 45, ...);

當(dāng)然，一次查詢(xún)比多查詢(xún)一千次要好。想象一下，如果有一萬(wàn)個(gè)客戶(hù)要處理，會(huì)發(fā)生什么情況！或者說(shuō)，如果我們還想顯示每個(gè)訂單中包含的項(xiàng)目，那簡(jiǎn)直就是天方夜譚！記住，這個(gè)技術(shù)的名字叫預(yù)加載，它幾乎在任何時(shí)候都能派上用場(chǎng)。

緩存配置！

Laravel 的靈活性的原因之一是它有大量的配置文件，這些文件是框架的一部分。想要改變圖片的存儲(chǔ)方式/位置？

好吧，只要修改 config/filesystems.php 文件就可以了（至少寫(xiě)到這里）。想要使用多個(gè)隊(duì)列驅(qū)動(dòng)？可以在 config/queue.php 中隨意描述。我剛剛統(tǒng)計(jì)了一下，發(fā)現(xiàn)針對(duì)框架的不同方面有 13 個(gè)配置文件，保證你無(wú)論想改什么都不會(huì)失望。鑒于 PHP 的特性，每當(dāng)一個(gè)新的 Web 請(qǐng)求進(jìn)來(lái)，Laravel 就會(huì)被喚醒，啟動(dòng)所有的東西，并解析所有的配置文件來(lái)找出這次該如何做不同的事情。如果這幾天什么都沒(méi)變，那就太傻了！每次請(qǐng)求都要重建配置文件是一種浪費(fèi)，這是可以 (實(shí)際上，必須) 避免的，解決的辦法是 Laravel 提供的一個(gè)簡(jiǎn)單的命令：

php artisan config:cache

這樣做的目的是把所有可用的配置文件合并成一個(gè)文件，并緩存在某個(gè)地方以便快速檢索。下一次有 Web 請(qǐng)求的時(shí)候，Laravel 會(huì)簡(jiǎn)單地讀取這個(gè)單一的文件并開(kāi)始工作。

也就是說(shuō)，配置緩存是一個(gè)極其微妙的操作，可能會(huì)在你的面前炸開(kāi)。最大的陷阱是一旦你發(fā)出這個(gè)命令，除了配置文件之外，其他地方的 env() 函數(shù)調(diào)用都會(huì)返回 null！

仔細(xì)想想確實(shí)有道理。如果你使用配置緩存，你就是在告訴框架：「你知道嗎，我覺(jué)得我已經(jīng)把東西設(shè)置得很好了，我 100% 確定我不希望它們改變?！?換句話(huà)說(shuō)，你希望環(huán)境保持靜態(tài)，這就是 .env 文件的作用。

說(shuō)到這里，這里有一些鐵定的、神圣的、不可違背的配置緩存規(guī)則：

只在生產(chǎn)系統(tǒng)上做。
只有在你非常非常確定要凍結(jié)配置的情況下才做。
萬(wàn)一出了問(wèn)題，用 php artisan cache:clear 撤銷(xiāo)設(shè)置。
祈禱對(duì)企業(yè)造成的損失不是很大！

減少自動(dòng)加載的服務(wù)

為了幫助大家, Laravel在喚醒時(shí)加載了大量的服務(wù), 這些服務(wù)在 config/app.php 文件中作為 'providers' 數(shù)組鍵的一部分。讓我們來(lái)看看我的情況：

/*
    |--------------------------------------------------------------------------
    | Autoloaded Service Providers
    |--------------------------------------------------------------------------
    |
    | The service providers listed here will be automatically loaded on the
    | request to your application. Feel free to add your own services to
    | this array to grant expanded functionality to your applications.
    |
    */

    'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        Illuminate\Auth\AuthServiceProvider::class,
        Illuminate\Broadcasting\BroadcastServiceProvider::class,
        Illuminate\Bus\BusServiceProvider::class,
        Illuminate\Cache\CacheServiceProvider::class,
        Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
        Illuminate\Cookie\CookieServiceProvider::class,
        Illuminate\Database\DatabaseServiceProvider::class,
        Illuminate\Encryption\EncryptionServiceProvider::class,
        Illuminate\Filesystem\FilesystemServiceProvider::class,
        Illuminate\Foundation\Providers\FoundationServiceProvider::class,
        Illuminate\Hashing\HashServiceProvider::class,
        Illuminate\Mail\MailServiceProvider::class,
        Illuminate\Notifications\NotificationServiceProvider::class,
        Illuminate\Pagination\PaginationServiceProvider::class,
        Illuminate\Pipeline\PipelineServiceProvider::class,
        Illuminate\Queue\QueueServiceProvider::class,
        Illuminate\redis\RedisServiceProvider::class,
        Illuminate\Auth\Passwords\PasswordResetServiceProvider::class,
        Illuminate\Session\SessionServiceProvider::class,
        Illuminate\Translation\TranslationServiceProvider::class,
        Illuminate\Validation\ValidationServiceProvider::class,
        Illuminate\View\ViewServiceProvider::class,

        /*
         * Package Service Providers...
         */

        /*
         * Application Service Providers...
         */
        App\Providers\AppServiceProvider::class,
        App\Providers\AuthServiceProvider::class,
        // App\Providers\BroadcastServiceProvider::class,
        App\Providers\EventServiceProvider::class,
        App\Providers\RouteServiceProvider::class,

    ],

我再一次數(shù)了數(shù)，一共列出了 27 項(xiàng)服務(wù)！現(xiàn)在，你可能需要所有的服務(wù)，但不太可能。

例如，我現(xiàn)在正好在構(gòu)建一個(gè) REST API，這意味著我不需要 Session Service Provider、View Service Provider 等。而且由于我是按照自己的方式來(lái)做一些事情，而不是按照框架的默認(rèn)值來(lái)做，所以我也可以禁用 Auth Service Provider、Pagination Service Provider、Translation Service Provider 等。總而言之，對(duì)于我的用例來(lái)說(shuō)，這些幾乎有一半是不必要的。

仔細(xì)審視一下你的應(yīng)用吧。它是否需要所有這些服務(wù)提供者？但是看在上帝的份上，請(qǐng)不要盲目地注釋掉這些服務(wù)，然后推送到生產(chǎn)中去！運(yùn)行所有的測(cè)試，在開(kāi)發(fā)機(jī)和暫存機(jī)上手動(dòng)檢查，并且在扣動(dòng)扳機(jī)之前要非常非常偏執(zhí)。

明智地使用中間件堆棧。

當(dāng)你需要對(duì)傳入的 Web 請(qǐng)求進(jìn)行一些自定義處理時(shí)，創(chuàng)建一個(gè)新的中間件就是答案?，F(xiàn)在，打開(kāi) app/Http/Kernel.php 并將中間件粘在 web 或 api 堆棧中是很有誘惑力的；這樣一來(lái)，它就會(huì)在整個(gè)應(yīng)用程序中變得可用，而且如果它沒(méi)有做一些侵入性的事情（例如，像日志或通知）。

然而，隨著應(yīng)用程序的增長(zhǎng)，如果所有（或大多數(shù)）這些全局中間件都存在于每個(gè)請(qǐng)求中，那么這個(gè)全局中間件的集合可能會(huì)成為應(yīng)用程序的一個(gè)無(wú)聲負(fù)擔(dān)，即使沒(méi)有業(yè)務(wù)原因。

換句話(huà)說(shuō)，要小心你在哪里添加/應(yīng)用新的中間件。在全局范圍內(nèi)添加一些東西可能會(huì)更方便，但從長(zhǎng)遠(yuǎn)來(lái)看，性能懲罰是非常高的。我知道如果每次有新的變化都要有選擇地應(yīng)用中間件，你要承受的痛苦，但這是我心甘情愿承受的痛苦，也是我所推薦的!

避免使用 ORM (有時(shí))

雖然 Eloquent 讓 DB 交互的很多方面變得愉悅，但它是以速度為代價(jià)的。作為一個(gè)映射器，ORM 不僅要從數(shù)據(jù)庫(kù)中獲取記錄，還要實(shí)例化模型對(duì)象，并用列數(shù)據(jù)對(duì)其進(jìn)行填充。

所以，如果你做一個(gè)簡(jiǎn)單的 $users = User::all()，比如有10000個(gè)用戶(hù)，框架會(huì)從數(shù)據(jù)庫(kù)中獲取 10000 行記錄，并在內(nèi)部做 10000 個(gè) new User()，并用相關(guān)數(shù)據(jù)填充他們的屬性。這是大量的工作在幕后進(jìn)行，如果數(shù)據(jù)庫(kù)是你的應(yīng)用成為瓶頸的地方，繞過(guò) ORM 有時(shí)是個(gè)好主意。

這對(duì)于復(fù)雜的 SQL 查詢(xún)來(lái)說(shuō)尤其如此，在這種情況下，你必須跳很多的圈子，寫(xiě)一個(gè)又一個(gè)的閉包，但最終還是能得到一個(gè)高效的查詢(xún)。在這種情況下，最好做一個(gè) DB::raw()，然后手工寫(xiě)查詢(xún)。

根據(jù) 這個(gè) 的性能研究, 即使是簡(jiǎn)單的插入， Eloquent 也會(huì)隨著記錄數(shù)量的增加而變慢

盡量使用緩存

Web 應(yīng)用優(yōu)化中最保守的秘密之一就是緩存。

對(duì)于新手來(lái)說(shuō)，緩存的意思是預(yù)先計(jì)算和存儲(chǔ)昂貴的結(jié)果(昂貴的 CPU 和內(nèi)存使用量)，并在重復(fù)相同的查詢(xún)時(shí)簡(jiǎn)單地返回。

例如，在一個(gè)電商商店里，可能會(huì)遇到，在 200 萬(wàn)種產(chǎn)品中，大多數(shù)時(shí)候人們都會(huì)對(duì)那些新鮮出爐的、在一定價(jià)格范圍內(nèi)的、針對(duì)特定年齡段的產(chǎn)品感興趣。在數(shù)據(jù)庫(kù)中查詢(xún)這些信息是很浪費(fèi)的——因?yàn)椴樵?xún)的內(nèi)容不會(huì)經(jīng)常變化，所以最好把這些結(jié)果存儲(chǔ)在我們可以快速訪問(wèn)的地方。

Laravel 內(nèi)置支持多種類(lèi)型的緩存。除了使用緩存驅(qū)動(dòng)和從底層構(gòu)建緩存系統(tǒng)外，你可能還想使用一些Laravel 包，方便模型緩存、查詢(xún)緩存等。

但是請(qǐng)注意, 在一定的簡(jiǎn)化用例之外, 預(yù)制的緩存包可能會(huì)帶來(lái)更多的問(wèn)題, 而不是解決這些問(wèn)題.

優(yōu)先選擇內(nèi)存緩存

當(dāng)你在 Laravel 中緩存一些東西時(shí)，你有幾個(gè)選項(xiàng)可以選擇將需要緩存的計(jì)算結(jié)果存儲(chǔ)在哪里。這些選項(xiàng)也被稱(chēng)為緩存驅(qū)動(dòng)。所以，雖然使用文件系統(tǒng)來(lái)存儲(chǔ)緩存結(jié)果是可能的，也是完全合理的，但這并不是緩存的真正目的。

理想情況下，你希望使用內(nèi)存中（完全活在 RAM 中）的緩存，比如 Redis、Memcached、MongoDB 等，這樣在較高的負(fù)載下，緩存就能起到至關(guān)重要的作用，而不是自己成為瓶頸。

現(xiàn)在，你可能會(huì)認(rèn)為擁有 SSD 磁盤(pán)和使用 RAM 棒幾乎是一樣的，但還差得遠(yuǎn)。即使是非正式的基準(zhǔn)測(cè)試也顯示，在速度方面，RAM優(yōu)于SSD的10-20倍。

在緩存方面，我最喜歡的系統(tǒng)是 Redis。它的速度快得離譜(每秒 10 萬(wàn)次讀取操作是很常見(jiàn)的)，對(duì)于非常大的緩存系統(tǒng)，可以很容易地演變成一個(gè) 集群。

緩存路由

就像應(yīng)用程序的配置一樣，路由不會(huì)隨著時(shí)間的推移而改變，是緩存的理想選擇。如果你像我一樣無(wú)法忍受大文件，并且最終把你的 web.php和 api.php 分割成幾個(gè)文件的話(huà)，這一點(diǎn)尤其適用。一個(gè)簡(jiǎn)單的Laravel命令就可以把所有可用的路由打包并保存起來(lái)，方便以后的訪問(wèn):

php artisan route:cache

而當(dāng)你最終要增加或改變路由時(shí)，只需這樣做即可。

php artisan route:clear

圖像優(yōu)化和 cdn

圖片是大多數(shù)網(wǎng)絡(luò)應(yīng)用的核心和靈魂。巧合的是，它們也是最大的帶寬消耗者，也是導(dǎo)致應(yīng)用程序/網(wǎng)站速度慢的最大原因之一。如果你只是簡(jiǎn)單地將上傳的圖片天真地存儲(chǔ)在服務(wù)器上，然后以 HTTP 響應(yīng)的方式發(fā)送回來(lái)，你就會(huì)讓一個(gè)巨大的優(yōu)化機(jī)會(huì)溜走。

我的第一個(gè)建議是不要在本地存儲(chǔ)圖片——有數(shù)據(jù)丟失的問(wèn)題要處理，而且取決于你的客戶(hù)在哪個(gè)地理區(qū)域，數(shù)據(jù)傳輸可能會(huì)非常緩慢。

相反，選擇像 Cloudinary 這樣的解決方案，它可以自動(dòng)動(dòng)態(tài)調(diào)整和優(yōu)化圖像的大小。

如果這不可能，使用類(lèi)似 Cloudflare 的東西來(lái)緩存和服務(wù)圖像，同時(shí)它們存儲(chǔ)在你的服務(wù)器上。

如果連這一點(diǎn)都做不到，調(diào)整一下你的網(wǎng)絡(luò)服務(wù)器軟件，壓縮資產(chǎn)并引導(dǎo)訪問(wèn)者的瀏覽器去緩存東西，就會(huì)有很大的不同。下面是一個(gè) Nginx 配置的片段。

server {

   # file truncated

    # gzip compression settings
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_vary on;

   # browser cache control
   location ~* \.(ico|css|js|gif|jpeg|jpg|png|woff|ttf|otf|svg|woff2|eot)$ {
         expires 1d;
         access_log off;
         add_header Pragma public;
         add_header Cache-Control "public, max-age=86400";
    }
}

我知道圖片優(yōu)化與 Laravel 無(wú)關(guān)，但這是一個(gè)如此簡(jiǎn)單而強(qiáng)大的技巧 (而且經(jīng)常被忽視)，所以我忍不住了。

自動(dòng)加載器優(yōu)化

自動(dòng)加載是 PHP 中一個(gè)整潔的、并不古老的功能，它可以說(shuō)是拯救了這門(mén)語(yǔ)言的末日。盡管如此，通過(guò)破譯給定的命名空間字符串來(lái)尋找和加載相關(guān)類(lèi)的過(guò)程是需要時(shí)間的，在生產(chǎn)部署中，如果需要高性能，可以避免這個(gè)過(guò)程。再一次，Laravel 有一個(gè)單一命令的解決方案來(lái)解決這個(gè)問(wèn)題:

composer install --optimize-autoloader --no-dev

與隊(duì)列交朋友

隊(duì)列是指當(dāng)有很多事情時(shí)，你如何處理這些事情，而且每件事情都需要幾毫秒才能完成。一個(gè)很好的例子是發(fā)送電子郵件——在網(wǎng)絡(luò)應(yīng)用中，一個(gè)廣泛的用例是當(dāng)用戶(hù)執(zhí)行一些操作時(shí)，發(fā)出幾封通知郵件。

例如，在一個(gè)新推出的產(chǎn)品中，你可能希望每當(dāng)有人下單超過(guò)一定值時(shí)，公司領(lǐng)導(dǎo)層（大約6-7個(gè)電子郵件地址）就會(huì)收到通知。假設(shè)你的郵件網(wǎng)關(guān)能在500ms內(nèi)響應(yīng)你的SMTP請(qǐng)求，那么在訂單確認(rèn)啟動(dòng)之前，用戶(hù)需要等待3-4秒。一個(gè)非常糟糕的用戶(hù)體驗(yàn)，我相信你會(huì)同意。

補(bǔ)救的辦法是在任務(wù)進(jìn)來(lái)的時(shí)候就把它們存儲(chǔ)起來(lái)，告訴用戶(hù)一切都很順利，然后再處理它們（幾秒鐘）。如果出現(xiàn)錯(cuò)誤，在宣布失敗之前，排隊(duì)的任務(wù)可以重試幾次。

雖然隊(duì)列系統(tǒng)使設(shè)置復(fù)雜化了一些 (并增加了一些監(jiān)控開(kāi)銷(xiāo))，但它在現(xiàn)代Web應(yīng)用中是不可缺少的。

資源優(yōu)化 (Laravel Mix)

對(duì)于你的 Laravel 應(yīng)用中的任何前端資源，請(qǐng)確保有一個(gè)管道可以編譯和最小化所有的資源文件。那些對(duì) Webpack，Gulp，Parcel 等打包器系統(tǒng)很熟悉的人不需要費(fèi)心，但如果你還沒(méi)有這樣做，Laravel Mix是一個(gè)可靠的推薦。

Mix 是一個(gè)輕量級(jí)的 (老實(shí)說(shuō),很討人喜歡！) 圍繞Webpack的打包器，它可以處理你所有的 CSS，SASS，JS 等文件。一個(gè)典型的 .mix.js 文件可以像這樣小，但仍然可以發(fā)揮出巨大的作用。

const mix = require('laravel-mix').mix.js('resources/js/app.js', 'public/js');

mix.js('resources/js/app.js', 'public/js')
    .sass('resources/sass/app.scss', 'public/css');

當(dāng)您準(zhǔn)備部署生產(chǎn)環(huán)境并運(yùn)行 npm run production 時(shí)，它將自動(dòng)處理導(dǎo)入，最小化，優(yōu)化以及整個(gè)工作流程。 Mix 不僅關(guān)心傳統(tǒng)的 JS和 CSS 文件，而且還關(guān)心您在應(yīng)用程序工作流程中可能使用的 Vue 和 React 組件。

感謝各位的閱讀，以上就是“如何優(yōu)化PHP和Laravel以提高Web應(yīng)用的性能”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)如何優(yōu)化PHP和Laravel以提高Web應(yīng)用的性能這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

文章名稱(chēng)：如何優(yōu)化PHP和Laravel以提高Web應(yīng)用的性能
本文網(wǎng)址：http://bm7419.com/article4/pccioe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站策劃、網(wǎng)站維護(hù)、Google、網(wǎng)頁(yè)設(shè)計(jì)公司、微信公眾號(hào)

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容