溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了Go1.18新特性工作區模糊測試及泛型如何使用的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Go1.18新特性工作區模糊測試及泛型如何使用文章都會有所收獲，下面我們一起來看看吧。
在實際的開發工作中，我們經常會同時修改存在依賴關系的多個module，例如在某個service模塊上實現需求的同時，也需要對項目組的某個common模塊做出修改，整個的工作流就會變成下面這樣：
可以看到，每次修改Common庫，都需要將代碼push到遠端，然后再修改本地service倉庫的依賴，再通過go mod tidy從遠端拉取Common代碼，不可謂不麻煩。
有些同學可能會問了，這種情況，在service倉庫的go.mod中添加一條replace不就能夠解決嗎？
但是，如果在go.mod中使用replace，在維護上需要付出額外的心智成本，萬一將帶有replace的go.mod推到遠端代碼庫了，其他同學不就一臉懵逼了？
假設此時我正在開發兩個新的模塊，分別是：
code.byted.org/SomeNewProject/Common code.byted.org/SomeNewProject/MyService
并且MyService依賴于Common。
在開發過程中，出于各種原因，有可能不會立即將代碼推送到遠端，那么此時假設我需要本地編譯MyService，就會出現go build（或者go mod tidy）自動下載依賴失敗，因為此時Common庫根本就沒有發布到代碼庫中。
出于和上述“多倉庫同時開發”相同的理由，replace也不應該被添加到MyService的go.mod文件中。
Go工作區模式最早出現于Go開發者Michael Matloob在2021年4月提出的一個名為“Multi-Module Workspaces in cmd/go”的提案。
這個提案中提出，新增一個go.work文件，并且在這個文件中指定一系列的本地路徑，這些本地路徑下的go module共同構成一個工作區（workspace），go命令可以操作這些路徑下的go module，在編譯時也會優先使用這些go module。
使用如下命令就可以初始化一個工作區，并且生成一個空的go.work文件：
go work init .
新生成的go.work文件內容如下：
go 1.18 directory ./.
go.work文件中，directory指示了工作區的各個module目錄，在編譯代碼時，會優先使用同一個workspace下的module。
在go.work中，也支持使用replace來指定使用本地代碼庫，但在大多數情況下，更好的做法是將依賴的本地代碼庫的路徑加入directory中。
因為go.work描述的是本地的工作區，所以也是不能提交到遠端代碼庫的，雖然可以在.gitignore中加入這個文件，但是最推薦的做法還是在本地代碼庫的上層目錄使用go.work。
例如上述的“多個新倉庫開始開發”的例子，假設我的兩個倉庫的本地路徑分別是：
/Users/bytedance/dev/my_new_project/common /Users/bytedance/dev/my_new_project/my_service
那么我就可以在“/Users/bytedance/dev/my_new_project”目錄下生成一個如下內容的go.work：
/Users/bytedance/dev/my_new_project/go.work: go 1.18 directory ( ./common ./my_service )
在上層目錄放置go.work，也可以將多個目錄組織成一個workspace，并且由于上層目錄本身不受git管理，所以也不用去管gitignore之類的問題，是比較省心的方式。
目前（go 1.18）僅go build會對go.work做出判斷，而go mod tidy并不care Go工作區。
從1.18起，模糊測試（Fuzzing Test）作為語言安全的一環，加入了Golang的testing標準庫。Golang加入模糊測試的原因非常明顯：安全是程序員在構建軟件的過程中必不可少且日益重要的考量因素。
Golang至今為止，已經在保障語言安全方面提供了很多的特性和工具，例如強制使用顯式類型轉換、禁止隱式類型轉換、對數組與切片的越界訪問檢查、通過go.sum對依賴包進行哈希校驗等等。
在進入云原生時代之后，Golang成為了云原生基礎設施與服務的頭部語言之一。這些系統對安全性的要求自然不言而喻。尤其是針對用戶的輸入，不被用戶的輸入弄出處理異常、崩潰、被操控是對這些系統的基本要求之一。
這就要求我們的系統在處理任何用戶輸入的時候都能保持穩定，但是傳統的質量保障手段，例如Code Review、靜態分析、人工測試、Unit Test等等，在面對日益復雜的系統時，自然就無法窮盡所有可能的輸入組合，尤其是一些非常不明顯的corner case。
而模糊測試就是業界在解決這方面問題的優秀實踐之一，Golang選擇支持它也就不難理解了。
模糊測試是一種通過數據構造引擎，輔以開發者可以提供的一些初始數據，自動構造出一些隨機數據，作為對程序的輸入來進行測試的一種方式。模糊測試可以幫助開發人員發現難以發現的穩定性、邏輯性甚至是安全性方面的錯誤，特別是當被測系統變得更加復雜時。
模糊測試在具體的實現上，通常可以不依賴于開發測試人員定義好的數據集，取而代之的則是一組通過數據構造引擎自行構造的一系列隨機數據。模糊測試會將這些數據作為輸入提供給待測程序，并且監測程序是否出現panic、斷言失敗、無限循環，或者其他什么異常情況。這些通過數據構造引擎生成的數據被稱為語料（corpus） 。另外模糊測試其實也是一種持續測試的手段，因為如果不限制執行的次數或者執行的最大時間，它就會一直不停的執行下去。
Golang的模糊測試由于被實現在了編譯器工具鏈中，所以采用了一種名為“覆蓋率引導的fuzzing”的入參生成技術，大致運行過程如下：
Golang的模糊測試在使用時，可以簡單地直接使用，也可以自己提供一些初始的語料。
模糊測試的函數也是放在xxx_test.go里的，編寫一個最簡單的模糊測試例子（明顯的除0錯誤）：
package main
import "testing"
import "fmt"
func FuzzDiv(f *testing.F) {
f.Fuzz(func(t *testing.T, a, b int) {
fmt.Println(a/b)
})
}可以看到類似于單元測試，模糊測試的函數名都是FuzzXxx格式，且接受一個testing.F指針對象。
然后在函數中使用f.Fuzz對指定的函數進行模糊測試，被測試的函數的第一個參數必須是“*testing.T”類型，后面可以跟任意多個基本類型的參數。
編寫完成之后，使用這樣的命令來啟動模糊測試：
go test -fuzz .
模糊測試默認會一直進行下去，只要被測試的函數不panic不出錯。可以通過“-fuzztime”選項來限制模糊測試的時間：
go test -fuzztime 10s -fuzz .
使用模糊測試對上述代碼進行測試時，會碰到產生panic的情況，此時模糊測試會輸出如下信息：
warning: starting with empty corpus
fuzz: elapsed: 0s, execs: 0 (0/sec), new interesting: 0 (total: 0)
fuzz: elapsed: 0s, execs: 1 (65/sec), new interesting: 0 (total: 0)
--- FAIL: FuzzDiv (0.02s)
--- FAIL: FuzzDiv (0.00s)
testing.go:1349: panic: runtime error: integer divide by zero
goroutine 11 [running]:
runtime/debug.Stack()
/Users/bytedance/.mytools/go/src/runtime/debug/stack.go:24 +0x90
testing.tRunner.func1()
/Users/bytedance/.mytools/go/src/testing/testing.go:1349 +0x1f2
panic({0x1196b80, 0x12e3140})
/Users/bytedance/.mytools/go/src/runtime/panic.go:838 +0x207
mydev/fuzz.FuzzDiv.func1(0x0?, 0x0?, 0x0?)
/Users/bytedance/Documents/dev_test/fuzz/main_test.go:8 +0x8c
reflect.Value.call({0x11932a0?, 0x11cbf68?, 0x13?}, {0x11be123, 0x4}, {0xc000010420, 0x3, 0x4?})
/Users/bytedance/.mytools/go/src/reflect/value.go:556 +0x845
reflect.Value.Call({0x11932a0?, 0x11cbf68?, 0x514?}, {0xc000010420, 0x3, 0x4})
/Users/bytedance/.mytools/go/src/reflect/value.go:339 +0xbf
testing.(*F).Fuzz.func1.1(0x0?)
/Users/bytedance/.mytools/go/src/testing/fuzz.go:337 +0x231
testing.tRunner(0xc000003a00, 0xc00007e3f0)
/Users/bytedance/.mytools/go/src/testing/testing.go:1439 +0x102
created by testing.(*F).Fuzz.func1
/Users/bytedance/.mytools/go/src/testing/fuzz.go:324 +0x5b8
Failing input written to testdata/fuzz/FuzzDiv/2058e4e611665fa289e5c0098bad841a6785bf79d30e47b96d8abcb0745a061c
To re-run:
go test -run=FuzzDiv/2058e4e611665fa289e5c0098bad841a6785bf79d30e47b96d8abcb0745a061c
FAIL
exit status 1
FAIL mydev/fuzz 0.059s
其中的：
Failing input written to testdata/fuzz/FuzzDiv/2058e4e611665fa289e5c0098bad841a6785bf79d30e47b96d8abcb0745a061c
這一行表示模糊測試將出現panic的測試入參保存到了這個文件里面，此時嘗試輸出這個文件的內容：
go test fuzz v1 int(-60) int(0)
就可以看到引發panic的入參，此時我們就可以根據入參檢查我們的代碼是哪里有問題。當然，這個簡單的例子就是故意寫了個除0錯誤。
Golang的模糊測試還允許開發者自行提供初始語料，初始語料可以通過“f.Add”方法提供，也可以將語料以上面的“Failing input”相同的格式，寫入“testdata/fuzz/FuzzXXX/自定義語料文件名”中。
目前Golang的模糊測試僅支持被測試的函數使用這些類型的參數：
[]byte, string, bool, byte, rune, float32, float64,
int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64
Golang在1.18中終于加入了對泛型的支持，有了泛型之后，我們可以這樣寫一些公共庫的代碼：
舊代碼（反射）：
func IsContainCommon(val interface{}, array interface{}) bool {
switch reflect.TypeOf(array).Kind() {
case reflect.Slice:
lst := reflect.ValueOf(array)
for index := 0; index < lst.Len(); index++ {
if reflect.DeepEqual(val, lst.Index(index).Interface()) {
return true
}
}
}
return false
}新代碼（泛型）：
func IsContainCommon[T any](val T, array []T) bool {
for _, item := range array {
if reflect.DeepEqual(val, item) {
return true
}
}
return false
}泛型在Golang中增加了三個新的重要特性：
在定義函數和類型時，支持使用類型參數（Type parameters）
將接口（interface）重新定義為“類型的集合”
泛型支持類型推導
下面逐個對這些內容進行簡單說明。
現在在定義函數和類型時，支持使用“類型參數”，類型參數的列表和函數參數列表很相似，只不過它使用的是方括號：
func Min[T constraints.Ordered](x, y T) T {
if x < y {
return x
}
return y
}上述的代碼中，給Min函數定義了一個參數類型T，這很類似于C++中的“template”，只不過在Golang中，可以為這種參數類型指定它需要滿足的“約束”。在這個例子中，使用的“約束”是“constraints.Ordered”。
然后就可以按照如下方式，使用這個函數了：
x := Min[int](1, 2) y := Min[float64](1.1, 2.2)
為泛型函數指定類型參數的過程叫做“實例化（Instantiation）”，也可以將實例化后的函數保存成為函數對象，并且進一步使用：
f := Min[int64] // 這一步保存了一個實例化的函數對象 n := f(123, 456)
同樣的，自定義的類型也支持泛型：
type TreeNode[T interface{}] struct {
left, right *TreeNode[T]
value T
}
func (t *TreeNode[T]) Find(x T) { ... }
var myBinaryTree TreeNode[int]如上述代碼，struct類型在使用泛型時，支持自己的成員變量和自己持有同樣的泛型類型。
下面稍微深入的講一下上述例子提到的“約束”。上文的例子中的“int”“float64”“int64”在實例化時，實際上是被作為“參數”傳遞給了“類型參數列表”，即上文例子中的“[T constraints.Ordered]”。
就像傳遞普通參數需要校驗參數的類型一樣，傳遞類型參數時也需要對被傳遞的類型參數進行校驗，檢查被傳遞的類型是否滿足要求。
例如上文例子中，使用“int”“float64”“int64”這幾個類型對Min函數進行實例化時，編譯器都會檢查這些參數是否滿足“constraints.Ordered”這個約束。而這個約束描述了所有可以使用“<”進行比較的類型的集合，這個約束本身也是一個interface。
在Go的泛型中，類型約束必須是一種interface，而“傳統”的Golang中對interface的定義是“一個接口定義了一組方法集合”，任何實現了這組方法集合的類型都實現了這個interface：
不過這里就出現了一個問題：“<”的比較顯然不是一個方法（Go當中不存在C++的運算符重載），而描述了這個約束的constraints.Ordered自身的確也是一個interface。
所以從1.18開始，Golang將Interface重新定義為“一組類型的集合”，按照以前對interface的看法，也可以將一個interface看成是“所有實現了這個interface的方法集合的類型所構成的集合”：
其實兩種看法殊途同歸，但是后者顯然可以更靈活，直接將一組具體類型指定成一個interface，即使這些類型沒有任何的方法。
例如在1.18中，可以這樣定義一個interface：
type MyInterface interface {
int|bool|string
}這樣的定義表示int/bool/string都可以被當作MyInterface進行使用。
那么回到constraints.Ordered，它的定義實際上是：
type Ordered interface {
Integer|Float|~string
}
type Float interface {
~float32|~float64
}
type Integer interface {
Signed|Unsigned
}
type Signed interface {
~int|~int8|~int16|~int32|~int64
}
type Unsigned interface {
~uint|~uint8|~uint16|~uint32|~uint64
}其中前置的“～”符號表示“任何底層類型是后面所跟著的類型的類型”，例如：
type MyString string
這樣定義的MyString是可以滿足“~string”的類型約束的。
最后，所有支持泛型的語言都會有的類型推導自然也不會缺席。類型推導功能可以允許使用者在調用泛型函數時，無需指定所有的類型參數。例如下面這個函數：
// 將F類型的slice變換為T類型的slice
// 關鍵字 any 等同于 interface{}
func Map[F, T any](src []F, f func(F) T) []T {
ret := make([]T, 0, len(src))
for _, item := range src {
ret = append(ret, f(item))
}
return ret
}在使用時可以這樣：
var myConv := func(i int)string {return fmt.Sprint(i)}
var src []int
var dest []string
dest = Map[int, string](src, myConv) // 明確指定F和T的類型
dest = Map[int](src, myConv) // 僅指定F的類型，T的類型交由編譯器推導
dest = Map(src, myConv) // 完全不指定類型，F和T都交由編譯器推導泛型函數在使用時，可以不指定具體的類型參數，也可以僅指定類型參數列表左邊的部分類型。當自動的類型推導失敗時，編譯器會報錯。
Golang泛型中的類型推導主要分為兩大部分：
函數參數類型推導：通過函數的入參，對類型參數對應的具體類型進行推導。
約束類型推導：通過已知具體類型的類型參數，來推斷出未知類型參數的具體類型。
而這兩種類型推導，都依賴一種名為“類型統一化（Type Unification）”的技術。
類型統一化是對兩個類型進行比較，這兩個類型有可能本身是一個類型參數，也有可能包含一個類型參數。
比較的過程是對這兩個類型的“結構”進行對比，并且要求被比較的兩個類型滿足下列條件：
剔除類型參數后，兩個類型的“結構”必須能夠匹配
剔除類型參數后，結構中剩余的具體類型必須相同
如果兩者均不含類型參數，那么兩者的類型必須完全相同，或者底層數據類型完全相同
這里說的“結構”，指的是類型定義中的slice、map、function等等，以及它們之間的任意嵌套。
滿足這幾個條件時，類型統一性對比才算做成功，編譯器才能進一步對類型參數進行推測，例如：
如果我們此時有“T1”、“T2”兩個類型參數，那么“[]map[int]bool”可以匹配如下類型：
[]map[int]bool // 它本身 T1 // T1被推斷為 []map[int]bool []T1 // T1被推斷為 map[int]bool []map[T1]T2 // T1被推斷為 int, T2被推斷為 bool
作為反例，“[]map[int]bool”顯然無法匹配這些類型：
int
struct{}
[]struct{}
[]map[T1]string
// etc...函數參數類型推導，顧名思義是在泛型函數被調用時，如果沒有被完全指定所有的類型參數，那么編譯器就會根據函數實際入參的類型，對類型參數所對應的具體類型進行推導，例如本文最開始的Min函數：
func Min[T constraints.Ordered](x, y T) T {
if x < y {
return x
}
return y
}
ans := Min(1, 2) // 此時類型參數T被推導為int和其他支持泛型的語言一樣，Golang的函數參數類型推導只支持“能夠從入參推導的類型參數”，如果類型參數用于標記返回類型，那么在使用時必須明確指定類型參數：
func MyFunc[T1, T2, T3 any](x T1) T2 {
// ...
var x T3
// ...
}
ans := MyFunc[int, bool, string](123) // 需要手動指定類似這樣的函數，部分的類型參數僅出現在返回值當中（或者僅出現在函數體中，不作為入參或出參出現），就無法使用函數參數類型推導，而必須明確手動指定類型。
還是拿Min函數作為例子，講解一下函數參數類型推導的過程：
func Min[T constraints.Ordered](x, y T) T {
if x < y {
return x
}
return y
}先來看看第一種情況：
Min(1, 2)
此時兩個入參均為無類型字面值常量，所以第一輪的類型統一化被跳過，且入參的具體類型沒有被確定，此時編譯器嘗試使用兩個參數的默認類型int，由于兩個入參在函數定義處的類型都是“T”，且兩者都使用默認類型int，所以此時T被成功推斷為int。
然后來看第二種情況：
Min(1, int64(2))
此時第二個參數有一個明確的類型int64，所以在第一輪的類型統一化中，T被推斷為int64，且在嘗試為第一輪漏掉的第一個參數“1”確定類型時，由于“1”是一個合法的int64類型值，所以T被成功推斷為int64。
再來看第三種情況：
Min(1.5, int64(2))
此時第二個參數有一個明確的類型int64，所以在第一輪的類型統一化中，T被推斷為int64，且在嘗試為第一輪漏掉的第一個參數“1.5”確定類型時，由于“1.5”不是一個合法的int64類型值，類型推導失敗，此時編譯器報錯。
最后看第四種情況：
Min(1, 2.5)
和第一種情況類似，第一輪的類型統一化被跳過，且兩個入參的具體類型沒有被確定，此時編譯器開始嘗試使用默認類型。兩個參數的默認類型分別是int和float64，由于在類型推導中，同一個類型參數T只能被確定為一種類型，所以此時類型推導也會失敗。
約束類型推導是Golang泛型的另一個強大武器，它可以允許編譯器通過一個類型參數來推導另一個類型參數的具體類型，也可以通過使用類型參數來保存調用者的類型信息。
約束類型推導可以允許使用其他類型參數來為某個類型參數指定約束，這類約束被稱為“結構化約束”，這種約束定義了類型參數必須滿足的數據結構，例如：
// 將一個整數slice中的每個元素都x2后返回
func DoubleSlice[S ~[]E, E constraints.Integer](slice S) S {
ret := make(S, 0, len(slice))
for _, item := range slice {
ret = append(ret, item + item)
}
return ret
}在這個函數的定義中，“[]E”就是一個簡寫的對S的結構化約束，其完整寫法應是“interface{[]E}”，即以類型集合的方式來定義的interface，且其中只包含一種定義“~[]E”，意為“底層數據類型是[]E的所有類型”。
注意，一個合法的結構化約束所對應的類型集合，應該滿足下列任意一個條件：
類型集合中只包含一種類型
類型集合中所有類型的底層數據類型均完全相同
在這個例子中，S使用的結構化約束中，所有滿足約束的類型的底層數據類型均為[]E，所以是一個合法的結構化約束。
當存在無法通過函數參數類型推導確定具體類型的類型參數，且類型參數列表中包含結構化約束時，編譯器會嘗試進行約束類型推導。
結合我們剛才的例子“DoubleSlice”函數，講一下約束類型推導的具體過程：
type MySlice []int
ans := DoubleSlice(MySlice{1, 2, 3})在這個調用中，首先執行的是普通的函數參數類型推導，這一步會得到一個這樣的推導結果：
S => MySlice
此時編譯器發現，還有一個類型參數E沒有被推導，且當前存在一個使用結構化約束的類型參數S，此時開始約束類型推導。
首先需要尋找已經完成類型推導的類型參數，在這個例子里是S，它的類型已經被推導出是MySlice。
然后會將S的實際類型“MySlice”，與S的結構化約束“~[]E”進行類型統一化，由于MySlice的底層類型是[]int，所以結構化匹配之后，得到了這樣的匹配結果：
E => int
此時所有的類型參數都已經被推斷，且符合各自的約束，類型推導結束。
假設有這樣一個函數：
func SomeComplicatedMethod[S ~[]M, M ~map[K]V, K comparable, V any](s S) {
// comparable 是一個內置的約束，表示所有可以使用 == != 運算符的類型
}然后我們這樣去調用它：
SomeComplicatedMethod([]map[string]int{})編譯時產生的類型推導過程如下，首先是函數參數類型推導的結果：
S => []map[string]int
然后對S使用約束類型推導，對比 []map[string]int 和 ~[]M，得到：
M => map[string]int
再繼續對M使用約束類型推導，對比 map[string]int 和 ~map[K]V，得到：
K => string V => int
至此類型推導成功完成。
約束類型推導的另一個作用就是，它能夠保存調用者的原始參數的類型信息。
還是以這一節的“DoubleSlice”函數做例子，假設我們現在實現一個更加“簡單”的版本：
func DoubleSliceSimple[E constraints.Integer](slice []E) []E {
ret := make([]E, 0, len(slice))
for _, item := range slice {
ret = append(ret, item + item)
}
return ret
}這個版本只有一個類型參數E。此時我們按照之前的方式去調用它：
type MySlice []int
ans := DoubleSliceSimple(MySlice{1, 2, 3}) // ans 的類型是 []int !!!此時的類型推導僅僅是最基礎的函數參數類型推導，編譯器會對MySlice和[]E直接做結構化比較，得出E的實際類型是int的結論。
此時DoubleSliceSimple這個函數返回的類型是[]E，也就是[]int，而不是調用者傳入的MySlice。而之前的DoubleSlice函數，通過定義了一個使用結構化約束的類型參數S，并且直接用S去匹配入參的類型，且返回值類型也是S，就可以保留調用者的原始參數類型。
目前Golang泛型依然還有不少的局限，幾個主要的局限點包括：
成員函數無法使用泛型
不能使用沒在約束定義中指定的方法，即使類型集合里所有的類型都實現了該方法
不能使用成員變量，即使類型集合里所有的類型都擁有該成員
下面分別舉例：
type MyStruct[T any] struct {
// ...
}
func (s *MyStruct[T]) Method[T2 any](param T2) { // 錯誤：成員函數無法使用泛型
// ...
}在這個例子中，MyStruct[T]的成員函數Method定義了一個只屬于自己的函數參數T2，然而這樣的操作目前是不被編譯器支持的（今后也很可能不會支持）。
type MyType1 struct {
// ...
}
func (t MyType1) Method() {}
type MyType2 struct {
// ...
}
func (t MyType2) Method() {}
type MyConstraint interface {
MyType1 | MyType2
}
func MyFunc[T MyConstraint](t T) {
t.Method() // 錯誤： MyConstraint 不包含 .Method() 方法
}這個例子中，MyConstraint集合中的兩個成員MyType1和MyType2盡管都實現了.Method()函數，但是也無法直接在泛型函數中調用。
如果需要調用，則應該將MyConstraint改寫為如下形式：
type MyConstraint interface {
MyType1 | MyType2
Method()
}type MyType1 struct {
Name string
}
type MyType2 struct {
Name string
}
type MyConstraint interface {
MyType1 | MyType2
}
func MyFunc[T MyConstraint](t T) {
fmt.Println(t.Name) // 錯誤： MyConstraint 不包含 .Name 成員
}在這個例子當中，雖然MyType1和MyType2都包含了一個Name成員，且類型都是string，也依然無法以任何方式在泛型函數當中直接使用。
因為類型約束本身是一個interface，而interface的定義中只能包含類型集合，以及成員函數列表。
關于“Go1.18新特性工作區模糊測試及泛型如何使用”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“Go1.18新特性工作區模糊測試及泛型如何使用”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
