前言

mysql中有兩個時間類型，timestamp與datetime，其中timestamp在存儲上是包含時區(qū)的，而datetime是不包含時區(qū)的字符串形式。而通常應(yīng)用下所說的時區(qū)問題，也指的是Java應(yīng)用使用了jdbc驅(qū)動時，存儲和讀取的時區(qū)不一致的問題，兩者可能會相差8小時或者13小時，今天，就來徹底搞懂為什么會發(fā)生這種所謂的時區(qū)問題。

首先需要明白，JDK以版本8為界，有兩套處理日期/時間的API：Date和JSR 310，其中，Date對象是絕對時間，Date對象里存的是自格林威治時間（GMT）1970年1月1日0點至Date所表示時刻所經(jīng)過的毫秒數(shù)。

Date類通過SimpleDateFormat格式化出來的yyyy-MM-dd HH:mm:ss形式的時間字符串，是帶了時區(qū)的本地時間，如果SimpleDateFormat沒有調(diào)用setTimeZone()顯示指定時區(qū)，那么默認(rèn)用的是jvm運行在的操作系統(tǒng)上的時區(qū)，我們開發(fā)機上的時區(qū)基本都是GMT+8。

我們首先需要搞明白上面的眾多名詞：GMT，UTC，時間標(biāo)準(zhǔn)，時區(qū)，以及與時區(qū)相關(guān)的夏令時的概念，才會對本次要講的內(nèi)容做很好的理解。

時間標(biāo)準(zhǔn)

GMT：Greenwich Mean Time

格林威治標(biāo)準(zhǔn)時間 ; 格林威治皇家天文臺為了海上霸權(quán)的擴張計劃，在十七世紀(jì)就開始進行天體觀測。為了天文觀測，選擇了穿過英國倫敦格林威治天文臺子午儀中心的一條經(jīng)線作為零度參考線，這條線，簡稱格林威治子午線。

英國倫敦格林威治定為0°經(jīng)線開始的地方，地球每15°經(jīng)度 被分為一個時區(qū)，共分為24個時區(qū)，GMT、UTC、DST、CST相鄰時區(qū)相差一小時；例例：中國北京位于東八區(qū)，GMT時間比北京時間慢8小時。

1972年之前，格林威治時間（GMT）一直是世界時間的標(biāo)準(zhǔn)。1972年之后，GMT 不再是一個時間標(biāo)準(zhǔn)了。

UTC：世界協(xié)調(diào)時間

UTC 是現(xiàn)在全球通用的時間標(biāo)準(zhǔn)，全球各地都同意將各自的時間進行同步協(xié)調(diào)。UTC 時間是經(jīng)過平均太陽時（以格林威治時間GMT為準(zhǔn)）、地軸運動修正后的新時標(biāo)以及以秒為單位的國際原子時所綜合精算而成。

其以原子時秒長為基礎(chǔ)，精確到秒，誤差在0.9s以內(nèi)， 是比GMT更為精確的世界時間。需要注意的是：協(xié)調(diào)世界時不與任何地區(qū)位置相關(guān)，也不代表此刻某地的時間，所以在說明某地時間時要加上時區(qū)，也就是說GMT并不等于UTC，而是等于UTC+0，只是格林尼治剛好在0時區(qū)上。GMT實際相當(dāng)于UTC+0，格林威治在0時區(qū)上。例如：中國標(biāo)準(zhǔn)時間比協(xié)調(diào)世界時早 8 小時，記為：UTC+8

時區(qū)

從格林威治本初子午線起，經(jīng)度每向東或者向西間隔15°，就劃分一個時區(qū)，在這個區(qū)域內(nèi)，大家使用同樣的標(biāo)準(zhǔn)時間。

但實際上，為了照顧到行政上的方便，常將1個國家或1個省份劃在一起。所以時區(qū)并不嚴(yán)格按南北直線來劃分，而是按自然條件來劃分。另外：由于目前，國際上并沒有一個批準(zhǔn)各國更改時區(qū)的機構(gòu)。一些國家會由于特定原因改變自己的時區(qū)。

各個時區(qū)的標(biāo)準(zhǔn)時間都有自己的簡寫，例如美國東部標(biāo)準(zhǔn)時間叫：EST，Estern Standard Time，但是有的簡寫會重復(fù)，這就是MySQL時區(qū)為什么會“錯亂”的原因之一，后續(xù)會講

但是CST同時是四個不同時區(qū)的縮寫，存在歧義

Central Standard Time (USA) UT-6:00 美國標(biāo)準(zhǔn)時間

Central Standard Time (Australia) UT+9:30 澳大利亞標(biāo)準(zhǔn)時間

China Standard Time UT+8:00 中國標(biāo)準(zhǔn)時間

Cuba Standard Time UT-4:00 古巴標(biāo)準(zhǔn)時間

需要注意的是，Java語言中的時間戳表示從1970年1月1日 00:00:00到現(xiàn)在所經(jīng)歷的秒數(shù)，與時區(qū)無關(guān)

夏令時

時區(qū)之外，還需要了解夏令時的概念，如今中國已不再使用夏令時，但是仍然有一些國家在使用夏令時，夏令時（DST: Daylight Saving Time），夏季節(jié)約時間，即夏令時；是為了利用夏天充足的光照而將時間調(diào)早一個小時，北美、歐洲的許多國家實行夏令時；

Java的Date類

可以看到，在時區(qū)設(shè)置不為空的情況下，toString方法可以以ISO時間標(biāo)準(zhǔn)表示方法輸出JDK所在地區(qū)的GMT標(biāo)準(zhǔn)時間

    public String toString() {
        // "EEE MMM dd HH:mm:ss zzz yyyy";
        BaseCalendar.Date date = normalize();
        StringBuilder sb = new StringBuilder(28);
        int index = date.getDayOfWeek();
        if (index == BaseCalendar.SUNDAY) {
            index = 8;
        }
        convertToAbbr(sb, wtb[index]).append(' ');                        // EEE
        convertToAbbr(sb, wtb[date.getMonth() - 1 + 2 + 7]).append(' ');  // MMM
        CalendarUtils.sprintf0d(sb, date.getDayOfMonth(), 2).append(' '); // dd

        CalendarUtils.sprintf0d(sb, date.getHours(), 2).append(':');   // HH
        CalendarUtils.sprintf0d(sb, date.getMinutes(), 2).append(':'); // mm
        CalendarUtils.sprintf0d(sb, date.getSeconds(), 2).append(' '); // ss
        TimeZone zi = date.getZone();
        if (zi != null) {
            sb.append(zi.getDisplayName(date.isDaylightTime(), TimeZone.SHORT, Locale.US)); // zzz
        } else {
            sb.append("GMT");
        }
        sb.append(' ').append(date.getYear());  // yyyy
        return sb.toString();
    }

getTime()方法可以獲取毫秒數(shù)，返回值類型是long

new Date().getTime();

示例

Date date=new Date();
System.out.println(date.toString());
System.out.println(date.toLocaleString());//棄用
System.out.println(date.toGMTString());//棄用
//Thu Jul 14 23:55:10 CST 2022
//2022-7-14 23:55:10
//14 Jul 2022 15:55:10 GMT

JDK8之前，Java對時區(qū)和偏移量都使用TimeZone類來表示的。Java不可以使用UTC+8。

getDefault()方法

sun.util.calendar.ZoneInfo[id="Asia/Shanghai",offset=28800000,dstSavings=0,useDaylight=false,transitions=31,lastRule=null]

時區(qū)轉(zhuǎn)換

可以使用SimpleDateFormat對時間在不同時區(qū)間進行轉(zhuǎn)換

//Java 中的 UTC和 GMT
jshell> Date now = new Date()
now ==> Thu Oct 30 16:59:27 CST 2021

jshell> import java.text.*

jshell> DateFormat df = DateFormat.getInstance()
df ==> java.text.SimpleDateFormat@ca92313f

jshell> df.setTimeZone(TimeZone.getTimeZone("GMT+8"))

jshell> df.format(now)
$5 ==> "2021/10/30 下午4:59

jshell> df.setTimeZone(TimeZone.getTimeZone("UTC+8"))

jshell> df.format(now)
$7 ==> "2021/10/30 上午8:59"

jshell> df.setTimeZone(TimeZone.getTimeZone("UTC"))

jshell> df.format(now)
$9 ==> "2021/10/30 上午8:59"

jshell> df.setTimeZone(TimeZone.getTimeZone("GMT"))

jshell> df.format(now)
$11 ==> "2021/10/30 上午8:59"

jshell> df.setTimeZone(TimeZone.getTimeZone("abc"))

jshell> df.format(now)
$13 ==> "2021/10/30 上午8:59"

//從上面的輸出可以看出，在當(dāng)前使用的 Java 版本中，設(shè)定時區(qū)偏移量時，是不能使用 UTC的，只能使用 GMT！另外，使用非法的時區(qū) ID 時，會將時區(qū)設(shè)定為零時區(qū)。

//GMT+8和 Asia/Shanghai
//通常我們會將日期表示成格式化的字符串，如 2021-10-31 10:34:00，然后將其解析為日期類型并使用，需要打印時再將日期類型轉(zhuǎn)換為字符串，例如：

jshell> import java.text.*

jshell> SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss")
sdf ==> java.text.SimpleDateFormat@4f76f1a0

jshell> DateFormat df = DateFormat.getInstance()
df ==> java.text.SimpleDateFormat@ca92313f

jshell> df.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"))

jshell> df.format(sdf.parse("2021-10-31 10:34:00"))
$6 ==> "2021/10/31 上午10:34"

jshell> df.setTimeZone(TimeZone.getTimeZone("GMT+8"))

jshell> df.format(sdf.parse("2021-10-31 10:34:00"))
$8 ==> "2021/10/31 上午10:34"

Java中的夏令時問題

前面談到了夏令時問題，所以會有這樣的疑問：GMT+8東八區(qū)時間一定是地區(qū)時間Asia/Shanghai嗎？下面是夏令時問題。

jshell> df.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"))

jshell> df.format(sdf.parse("1986-05-04 02:00:00"))
$10 ==> "1986/5/4 上午3:00"

jshell> df.setTimeZone(TimeZone.getTimeZone("GMT+8"))

jshell> df.format(sdf.parse("1986-05-04 02:00:00"))
$12 ==> "1986/5/4 上午2:00"

當(dāng)我們使用1986-05-04 02:00:00這個時間戳?xí)r：

時區(qū)設(shè)置為 GMT+8，字符串轉(zhuǎn)日期，再將日期轉(zhuǎn)成字符串，得到的日期和時間跟輸入的時間戳是一樣的，時區(qū)設(shè)置為 Asia/Shanghai，經(jīng)過轉(zhuǎn)換之后，輸出的時間變成了上午三點，比輸入的上午兩點多了一小時，這是因為夏令時造成的。

由此可以看到，僅僅使用偏移量無法準(zhǔn)確的描述一個地區(qū)的時間，因此Java推出了JSR 310使用時區(qū)來描述當(dāng)?shù)氐臅r間。

TIPS: GMT-8和Asia/Shanghai

• GMT-8是東八區(qū)，北京時間和東八區(qū)一致。
• Asia/Shanghai是已地區(qū)命名的地區(qū)標(biāo)準(zhǔn)時，這個地區(qū)標(biāo)準(zhǔn)時會兼容歷史各個時間節(jié)點。中國1986-1991年實行夏令時，夏天和冬天差1個小時，Asia/Shanghai會兼容這個時間段。1992年以后，在中國，GMT-8和Asia/Shanghai是一樣的時間，1986-1991之間，夏天會有一小時時差。

JSR310

時區(qū)和偏移量在概念和實際作用上是有較大區(qū)別的，主要體現(xiàn)在：UTC偏移量僅僅記錄了偏移的小時分鐘而已，除此之外無地理/時區(qū)含義。比如：+08:00的意思是比UTC時間早8小時，沒有地理/時區(qū)含義，相應(yīng)的-03:30代表的意思僅僅是比UTC時間晚3個半小時。

時區(qū)是特定于地區(qū)而言的，它和地理上的地區(qū)（包括規(guī)則）強綁定在一起。比如整個中國都叫東八區(qū)，紐約在西五區(qū)等等。

中國沒有夏令時，所有東八區(qū)對應(yīng)的偏移量永遠是+8；紐約有夏令時，因此它的偏移量可能是-4也可能是-5，因此規(guī)定了時區(qū)后，我們可以根據(jù)夏令時準(zhǔn)確的計算當(dāng)?shù)貢r間

ZoneId

在JDK 8之前，Java使用java.util.TimeZone來表示時區(qū)。而在JDK 8里分別使用了ZoneId表示時區(qū)，ZoneOffset表示UTC的偏移量。

ZoneId在系統(tǒng)內(nèi)是唯一的，它共包含三種類型的ID：

• 最簡單的ID類型：ZoneOffset，它由’Z’和以’+‘或’-'開頭的id組成。如：Z、+18:00、-18:00

• 另一種類型的ID是帶有某種前綴形式的偏移樣式ID，例如’GMT+2’或’UTC+01:00’?？勺R別的（合法的）前綴是’UTC’， ‘GMT’和’UT’

• 第三種類型是基于區(qū)域的ID（推薦使用）。基于區(qū)域的ID必須包含兩個或多個字符，且不能以’UTC’、‘GMT’、‘UT’ '+‘或’-'開頭。基于區(qū)域的id由配置定義好的，如Europe/Paris

System.out.println(ZoneId.systemDefault());//Asia/Shanghai

ZoneId底層使用的也是TimeZone

    /**
     * Gets the system default time-zone.
     * <p>
     * This queries {@link TimeZone#getDefault()} to find the default time-zone
     * and converts it to a {@code ZoneId}. If the system default time-zone is changed,
     * then the result of this method will also change.
     *
     * @return the zone ID, not null
     * @throws DateTimeException if the converted zone ID has an invalid format
     * @throws ZoneRulesException if the converted zone region ID cannot be found
     */
    public static ZoneId systemDefault() {
        return TimeZone.getDefault().toZoneId();
    }

ZoneOffset

時區(qū)偏移量是時區(qū)與格林威治/UTC之間的時間差。這通常是固定的小時數(shù)和分鐘數(shù)。世界不同的地區(qū)有不同的時區(qū)偏移量。在ZoneId類中捕獲關(guān)于偏移量如何隨一年的地點和時間而變化的規(guī)則（主要是夏令時規(guī)則），所以繼承自ZoneId。

JSR 310對日期、時間進行了分開表示（LocalDate、LocalTime、LocalDateTime），對本地時間和帶時區(qū)的時間進行了分開管理。LocalXXX表示本地時間，也就是說是當(dāng)前JVM所在時區(qū)的時間；ZonedXXX表示是一個帶有時區(qū)的日期時間，它們能非常方便的互相完成轉(zhuǎn)換。

// 本地日期/時間
System.out.println("================本地時間================");
System.out.println(LocalDate.now());
System.out.println(LocalTime.now());
System.out.println(LocalDateTimenow());

// 時區(qū)時間
System.out.println("================帶時區(qū)的時間ZonedDateTime================");
System.out.println(ZonedDateTime.now()); // 使用系統(tǒng)時區(qū)
System.out.println(ZonedDateTime.now(ZoneId.of("America/New_York"))); // 自己指定時區(qū)
System.out.println(ZonedDateTime.now(Clock.systemUTC())); // 自己指定時區(qū)
System.out.println("================帶時區(qū)的時間OffsetDateTime================");
System.out.println(OffsetDateTime.now()); // 使用系統(tǒng)時區(qū)
System.out.println(OffsetDateTime.now(ZoneId.of("America/New_York"))); // 自己指定時區(qū)
System.out.println(OffsetDateTime.now(Clock.systemUTC())); // 自己指定時區(qū)

MySQL中的時區(qū)

Java的時間實際上是經(jīng)過jdbc轉(zhuǎn)換為字符串的形式寫入數(shù)據(jù)庫，查詢時同理以字符串的形式轉(zhuǎn)換為Java Date類型，所以需要分析jdbc驅(qū)動，發(fā)現(xiàn)實際上在調(diào)用jdbc的setTimestamp()方法時，com.mysql.cj.jdbc.ClientPreparedStatement#setTimestamp()，這里面會根據(jù)serverTimezone指定的時區(qū)，將對應(yīng)的Timestamp對象轉(zhuǎn)換為serverTimezone指定時區(qū)的本地時間字符串。如果jdbc連接串的serverTimezone配置的時區(qū)和數(shù)據(jù)庫配置的時區(qū)不一致時，查詢的時間的時區(qū)以serverTimezone為準(zhǔn)。

查看MySQL數(shù)據(jù)庫當(dāng)前時區(qū)：

SHOW variables LIKE '%time_zone%';

Variable_name   |Value |
----------------+------+
system_time_zone|CST   |
time_zone       |SYSTEM|

發(fā)現(xiàn)MySQL默認(rèn)配置的是CST，然而對于CST，MySQL和Java卻對其有不同的解讀。

• MySQL中，CST表示的是：中國標(biāo)準(zhǔn)時間(UTC+08:00)
• Java中，CST表示的是：美國標(biāo)準(zhǔn)時間(UTC-05:00或UTC-06:00)

所以出現(xiàn)時區(qū)問題的根本原因是由于Java和MySQL服務(wù)端對CST時區(qū)的不同解讀，最終導(dǎo)致了Java與MySQL時間不一致的問題。

比如一個時間值是東8區(qū)的2020-02-23 08:00:00，在Java代碼中存儲的是Date類型的絕對時間，由于serverTimeZone未配置，讀取MySQL默認(rèn)的time_zone為CST（中國標(biāo)準(zhǔn)時間），由于Java認(rèn)為CST是美國標(biāo)準(zhǔn)時間的縮寫，因此MySQL驅(qū)動會將這個Date對象轉(zhuǎn)為字符串類型的2020-02-22 19:00:00，將sql發(fā)送給MySQL，然后MySQL數(shù)據(jù)庫接收到這個時間字符串2020-02-22 19:00:00后，由于數(shù)據(jù)庫時區(qū)配置是CST中國標(biāo)準(zhǔn)時間東8區(qū)，數(shù)據(jù)庫會認(rèn)為是東8區(qū)的2020-02-22 19:00:00。查詢時MySQL返回了東8區(qū)的時間字符串2020-02-22 19:00:00，Java拿到后認(rèn)為是CST美國標(biāo)準(zhǔn)時間的2020-02-22 19:00:00，最后以UTC+8標(biāo)準(zhǔn)時間輸出到控制臺，就顯示為2020-02-23 08:00:00，因此，當(dāng)連接串不指定時區(qū)時，也不會出現(xiàn)問題。

但是，如果在這種情況下，我們把數(shù)據(jù)庫連接串的時區(qū)配置為真正的中國時區(qū)Aisa\Shanghai，那么，問題就出現(xiàn)了，根據(jù)上面的解釋，Java應(yīng)用最后應(yīng)該會輸出的時間會少13個小時，這就是出現(xiàn)時區(qū)問題的根本原因。

以下是jdbc獲取時區(qū)配置的代碼：

    /**
     * Configures the client's timezone if required.
     * 
     * @throws CJException
     *             if the timezone the server is configured to use can't be
     *             mapped to a Java timezone.
     */
    public void configureTimezone() {
        String configuredTimeZoneOnServer = this.serverSession.getServerVariable("time_zone");

        if ("SYSTEM".equalsIgnoreCase(configuredTimeZoneOnServer)) {
            configuredTimeZoneOnServer = this.serverSession.getServerVariable("system_time_zone");
        }

        String canonicalTimezone = getPropertySet().getStringProperty(PropertyKey.serverTimezone).getValue();

        if (configuredTimeZoneOnServer != null) {
            // user can override this with driver properties, so don't detect if that's the case
            if (canonicalTimezone == null || StringUtils.isEmptyOrWhitespaceOnly(canonicalTimezone)) {
                try {
                    canonicalTimezone = TimeUtil.getCanonicalTimezone(configuredTimeZoneOnServer, getExceptionInterceptor());
                } catch (IllegalArgumentException iae) {
                    throw ExceptionFactory.createException(WrongArgumentException.class, iae.getMessage(), getExceptionInterceptor());
                }
            }
        }

        if (canonicalTimezone != null && canonicalTimezone.length() > 0) {
            this.serverSession.setServerTimeZone(TimeZone.getTimeZone(canonicalTimezone));

            //
            // The Calendar class has the behavior of mapping unknown timezones to 'GMT' instead of throwing an exception, so we must check for this...
            //
            if (!canonicalTimezone.equalsIgnoreCase("GMT") && this.serverSession.getServerTimeZone().getID().equals("GMT")) {
                throw ExceptionFactory.createException(WrongArgumentException.class, Messages.getString("Connection.9", new Object[] { canonicalTimezone }),
                        getExceptionInterceptor());
            }
        }

        this.serverSession.setDefaultTimeZone(this.serverSession.getServerTimeZone());
    }

如果MySQL時區(qū)和serverTimezone配置不一樣呢，這種情況會發(fā)生時區(qū)問題嗎？比如把數(shù)據(jù)庫時區(qū)配置為+9:00時區(qū)，然后把jdbc的url上的serverTimezone配置為與數(shù)據(jù)庫不一致的GMT+8時區(qū)時，會發(fā)生時區(qū)問題嗎？

比如一個時間值是東8區(qū)的2020-02-23 08:00:00，在Java代碼中存儲的是Date類型的絕對時間，由于serverTimeZone配置的是東8區(qū)，MySQL驅(qū)動會將這個Date對象轉(zhuǎn)為字符串類型的2020-02-23 08:00:00，將sql發(fā)送給MySQL，然后MySQL數(shù)據(jù)庫接收到這個時間字符串2020-02-23 08:00:00后，由于數(shù)據(jù)庫時區(qū)配置是東9區(qū)，它會以東9區(qū)解析這個時間字符串，這時數(shù)據(jù)庫保存的時間是東9區(qū)的2020-02-23 08:00:00，也就是東8區(qū)的2020-02-23 07:00:00，**這里需要注意的是，時間實際上已經(jīng)出現(xiàn)了問題，保存的時間偏差了1個小時。**但是查詢時MySQL返回了東9區(qū)的時間字符串2020-02-23 08:00:00，而Java又認(rèn)為這是東8區(qū)的2020-02-23 08:00:00，和存儲時一致。也是沒有時區(qū)的問題。

但是，如果在這種情況下，我們把數(shù)據(jù)庫連接串的時區(qū)也配置為+9:00時區(qū)，那么，問題就出現(xiàn)了，根據(jù)上面的解釋，Java應(yīng)用最后應(yīng)該會輸出的時間會多1個小時，這就是出現(xiàn)時區(qū)問題的根本原因。

總結(jié)

1、大多數(shù)團隊會規(guī)定api中傳遞時間要用unix時間綴，因為如果你傳一個2020-02-23 08:00:00時間值，它到底是哪個時區(qū)的8點呢？對于unix時間綴，就不會有此問題，因為它是絕對時間。而如果某些特殊原因，一定要使用時間字符串，最好使用ISO8601規(guī)范那種帶時區(qū)的時間串，比如：2020-02-23T08:00:00+08:00。

2、Mybatis中Entity定義要與數(shù)據(jù)庫定義一致，數(shù)據(jù)庫中是timestamp，那么Entity中要定義為Date對象，因為MySQL驅(qū)動在執(zhí)行sql時，會自動根據(jù)serverTimezone配置幫你轉(zhuǎn)換為數(shù)據(jù)庫時區(qū)的時間串，如果你自己來轉(zhuǎn)換，你極有可能因為忘記調(diào)用setTimeZone()方法，而使用當(dāng)前java應(yīng)用所在機器的默認(rèn)時區(qū)，一旦java應(yīng)用所在機器的時區(qū)與數(shù)據(jù)庫的時區(qū)不一致，就會出現(xiàn)時區(qū)問題。

3、jdbc的serverTimezone參數(shù)，要配置正確，當(dāng)不配置時，MySQL驅(qū)動會自動讀取MySQL server的時區(qū)，此時一定要將MySQL server的時區(qū)指定為清晰的時區(qū)(如：+08:00)，切勿使用CST。

4、如果數(shù)據(jù)庫時區(qū)修改后，jdbc的serverTimezone也要跟著修改，并重啟Java應(yīng)用，就算沒有配置serverTimezone，也需要重啟，因為MySQL驅(qū)動初始化連接時，會將當(dāng)前數(shù)據(jù)庫時區(qū)緩存到一個java變量中，不重啟Java應(yīng)用它不會變。

到此這篇關(guān)于一文徹底搞懂MySQL TimeStamp時區(qū)問題的文章就介紹到這了,更多相關(guān)MySQL TimeStamp時區(qū)問題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！