Go 系列 · Wasabi

Go 语言代码安全指南

Wed, 01 Dec 2021 16:04:20 +0000

这是一些关于 Go 安全编码方案，旨在从源头规避漏洞。

通用类

1. 代码实现类

1.1 内存管理

1.1.1【必须】切片长度校验

在对slice进行操作时，必须判断长度是否合法，防止程序panic

// bad: 未判断data的长度，可导致 index out of range
func decode(data []byte) bool {
	if data[0] == 'F' && data[1] == 'U' && data[2] == 'Z' && data[3] == 'Z' && data[4] == 'E' && data[5] == 'R' {
		fmt.Println("Bad")
		return true
	}
	return false
}

// bad: slice bounds out of range
func foo() {
	var slice = []int{0, 1, 2, 3, 4, 5, 6}
	fmt.Println(slice[:10])
}

// good: 使用data前应判断长度是否合法
func decode(data []byte) bool {
	if len(data) == 6 {
		if data[0] == 'F' && data[1] == 'U' && data[2] == 'Z' && data[3] == 'Z' && data[4] == 'E' && data[5] == 'R' {
			fmt.Println("Good")
			return true
		}
	}
	return false
}

1.1.2【必须】nil指针判断

进行指针操作时，必须判断该指针是否为nil，防止程序panic，尤其在进行结构体Unmarshal时

type Packet struct {
	PackeyType    uint8
	PackeyVersion uint8
	Data          *Data
}

type Data struct {
	Stat uint8
	Len  uint8
	Buf  [8]byte
}

func (p *Packet) UnmarshalBinary(b []byte) error {
	if len(b) < 2 {
		return io.EOF
	}

	p.PackeyType = b[0]
	p.PackeyVersion = b[1]

	// 若长度等于2，那么不会new Data
	if len(b) > 2 {
		p.Data = new(Data)
	}
	return nil
}

// bad: 未判断指针是否为nil
func main() {
	packet := new(Packet)
	data := make([]byte, 2)
	if err := packet.UnmarshalBinary(data); err != nil {
		fmt.Println("Failed to unmarshal packet")
		return
	}

	fmt.Printf("Stat: %v\n", packet.Data.Stat)
}

// good: 判断Data指针是否为nil
func main() {
	packet := new(Packet)
	data := make([]byte, 2)

	if err := packet.UnmarshalBinary(data); err != nil {
		fmt.Println("Failed to unmarshal packet")
		return
	}

	if packet.Data == nil {
		return
	}

	fmt.Printf("Stat: %v\n", packet.Data.Stat)
}

1.1.3【必须】整数安全

在进行数字运算操作时，需要做好长度限制，防止外部输入运算导致异常：
- 确保无符号整数运算时不会反转
- 确保有符号整数运算时不会出现溢出
- 确保整型转换时不会出现截断错误
- 确保整型转换时不会出现符号错误
以下场景必须严格进行长度限制：
- 作为数组索引
- 作为对象的长度或者大小
- 作为数组的边界（如作为循环计数器）

// bad: 未限制长度，导致整数溢出
func overflow(numControlByUser int32) {
	var numInt int32 = 0
	numInt = numControlByUser + 1
	// 对长度限制不当，导致整数溢出
	fmt.Printf("%d\n", numInt)
	// 使用numInt，可能导致其他错误
}

func main() {
	overflow(2147483647)
}

// good
func overflow(numControlByUser int32) {
	var numInt int32 = 0
	numInt = numControlByUser + 1
	if numInt < 0 {
		fmt.Println("integer overflow")
		return
	}
	fmt.Println("integer ok")
}

func main() {
	overflow(2147483647)
}

1.1.4【必须】make分配长度验证

在进行make分配内存时，需要对外部可控的长度进行校验，防止程序panic。

// bad
func parse(lenControlByUser int, data []byte) {
	size := lenControlByUser
	// 对外部传入的size，进行长度判断以免导致panic
	buffer := make([]byte, size)
	copy(buffer, data)
}

// good
func parse(lenControlByUser int, data []byte) ([]byte, error) {
	size := lenControlByUser
	// 限制外部可控的长度大小范围
	if size > 64*1024*1024 {
		return nil, errors.New("value too large")
	}
	buffer := make([]byte, size)
	copy(buffer, data)
	return buffer, nil
}

1.1.5【必须】禁止SetFinalizer和指针循环引用同时使用

当一个对象从被GC选中到移除内存之前，runtime.SetFinalizer()都不会执行，即使程序正常结束或者发生错误。由指针构成的“循环引用”虽然能被GC正确处理，但由于无法确定Finalizer依赖顺序，从而无法调用runtime.SetFinalizer()，导致目标对象无法变成可达状态，从而造成内存无法被回收。

// bad
func foo() {
	var a, b Data
	a.o = &b
	b.o = &a

	// 指针循环引用，SetFinalizer()无法正常调用
	runtime.SetFinalizer(&a, func(d *Data) {
		fmt.Printf("a %p final.\n", d)
	})
	runtime.SetFinalizer(&b, func(d *Data) {
		fmt.Printf("b %p final.\n", d)
	})
}

func main() {
	for {
		foo()
		time.Sleep(time.Millisecond)
	}
}

1.1.6【必须】禁止重复释放channel

重复释放一般存在于异常流程判断中，如果恶意攻击者构造出异常条件使程序重复释放channel，则会触发运行时panic，从而造成DoS攻击。

// bad
func foo(c chan int) {
	defer close(c)
	err := processBusiness()
	if err != nil {
		c <- 0
		close(c) // 重复释放channel
		return
	}
	c <- 1
}

// good
func foo(c chan int) {
	defer close(c) // 使用defer延迟关闭channel
	err := processBusiness()
	if err != nil {
		c <- 0
		return
	}
	c <- 1
}

1.1.7【必须】确保每个协程都能退出

启动一个协程就会做一个入栈操作，在系统不退出的情况下，协程也没有设置退出条件，则相当于协程失去了控制，它占用的资源无法回收，可能会导致内存泄露。

// bad: 协程没有设置退出条件
func doWaiter(name string, second int) {
	for {
		time.Sleep(time.Duration(second) * time.Second)
		fmt.Println(name, " is ready!")
	}
}

1.1.8【推荐】不使用unsafe包

由于unsafe包绕过了 Golang 的内存安全原则，一般来说使用该库是不安全的，可导致内存破坏，尽量避免使用该包。若必须要使用unsafe操作指针，必须做好安全校验。

// bad: 通过unsafe操作原始指针
func unsafePointer() {
	b := make([]byte, 1)
	foo := (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&b[0])) + uintptr(0xfffffffe)))
	fmt.Print(*foo + 1)
}

// [signal SIGSEGV: segmentation violation code=0x1 addr=0xc100068f55 pc=0x49142b]

1.1.9【推荐】不使用slice作为函数入参

slice在作为函数入参时，函数内对slice的修改可能会影响原始数据

  // bad
  // slice作为函数入参时包含原始数组指针
  func modify(array []int) {
      array[0] = 10 // 对入参slice的元素修改会影响原始数据
  }
  
  func main() {
      array := []int{1, 2, 3, 4, 5}
  
      modify(array)
      fmt.Println(array) // output：[10 2 3 4 5]
  }

  // good
  // 数组作为函数入参，而不是slice
  func modify(array [5]int) {
    array[0] = 10
  }

  func main() {
      // 传入数组，注意数组与slice的区别
      array := [5]int{1, 2, 3, 4, 5}
  
      modify(array)
      fmt.Println(array)
  }

1.2 文件操作

1.2.1【必须】路径穿越检查

在进行文件操作时，如果对外部传入的文件名未做限制，可能导致任意文件读取或者任意文件写入，严重可能导致代码执行。

// bad: 任意文件读取
func handler(w http.ResponseWriter, r *http.Request) {
	path := r.URL.Query()["path"][0]

	// 未过滤文件路径，可能导致任意文件读取
	data, _ := ioutil.ReadFile(path)
	w.Write(data)

	// 对外部传入的文件名变量，还需要验证是否存在../等路径穿越的文件名
	data, _ = ioutil.ReadFile(filepath.Join("/home/user/", path))
	w.Write(data)
}

// bad: 任意文件写入
func unzip(f string) {
	r, _ := zip.OpenReader(f)
	for _, f := range r.File {
		p, _ := filepath.Abs(f.Name)
		// 未验证压缩文件名，可能导致../等路径穿越，任意文件路径写入
		ioutil.WriteFile(p, []byte("present"), 0640)
	}
}

// good: 检查压缩的文件名是否包含..路径穿越特征字符，防止任意写入
func unzipGood(f string) bool {
	r, err := zip.OpenReader(f)
	if err != nil {
		fmt.Println("read zip file fail")
		return false
	}
	for _, f := range r.File {
		if !strings.Contains(f.Name, "..") {
			p, _ := filepath.Abs(f.Name)
			ioutil.WriteFile(p, []byte("present"), 0640)
		} else {
			return false
		}
	}
	return true
}

1.2.2【必须】文件访问权限

根据创建文件的敏感性设置不同级别的访问权限，以防止敏感数据被任意权限用户读取。例如，设置文件权限为：-rw-r-----

ioutil.WriteFile(p, []byte("present"), 0640)

1.3 系统接口

1.3.1【必须】命令执行检查

使用exec.Command、exec.CommandContext、syscall.StartProcess、os.StartProcess等函数时，第一个参数（path）直接取外部输入值时，应使用白名单限定可执行的命令范围，不允许传入bash、cmd、sh等命令；
使用exec.Command、exec.CommandContext等函数时，通过bash、cmd、sh等创建shell，-c后的参数（arg）拼接外部输入，应过滤\n $ & ; | ’ " ( ) `等潜在恶意字符；

// bad
func foo() {
	userInputedVal := "&& echo 'hello'" // 假设外部传入该变量值
	cmdName := "ping " + userInputedVal

	// 未判断外部输入是否存在命令注入字符，结合sh可造成命令注入
	cmd := exec.Command("sh", "-c", cmdName)
	output, _ := cmd.CombinedOutput()
	fmt.Println(string(output))

	cmdName := "ls"
	// 未判断外部输入是否是预期命令
	cmd := exec.Command(cmdName)
	output, _ := cmd.CombinedOutput()
	fmt.Println(string(output))
}

// good
func checkIllegal(cmdName string) bool {
	if strings.Contains(cmdName, "&") || strings.Contains(cmdName, "|") || strings.Contains(cmdName, ";") ||
		strings.Contains(cmdName, "$") || strings.Contains(cmdName, "'") || strings.Contains(cmdName, "`") ||
		strings.Contains(cmdName, "(") || strings.Contains(cmdName, ")") || strings.Contains(cmdName, "\"") {
		return true
	}
	return false
}

func main() {
	userInputedVal := "&& echo 'hello'"
	cmdName := "ping " + userInputedVal

	if checkIllegal(cmdName) { // 检查传给sh的命令是否有特殊字符
		return // 存在特殊字符直接return
	}

	cmd := exec.Command("sh", "-c", cmdName)
	output, _ := cmd.CombinedOutput()
	fmt.Println(string(output))
}

1.4 通信安全

1.4.1【必须】网络通信采用TLS方式

明文传输的通信协议目前已被验证存在较大安全风险，被中间人劫持后可能导致许多安全风险，因此必须采用至少TLS的安全通信方式保证通信安全，例如gRPC/Websocket都使用TLS1.3。

// good
func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
		w.Header().Add("Strict-Transport-Security", "max-age=63072000; includeSubDomains")
		w.Write([]byte("This is an example server.\n"))
	})

	// 服务器配置证书与私钥
	log.Fatal(http.ListenAndServeTLS(":443", "yourCert.pem", "yourKey.pem", nil))
}

1.4.2【推荐】TLS启用证书验证

TLS证书应当是有效的、未过期的，且配置正确的域名，生产环境的服务端应启用证书验证。

// bad
import (
	"crypto/tls"
	"net/http"
)

func doAuthReq(authReq *http.Request) *http.Response {
	tr := &http.Transport{
		TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
	}
	client := &http.Client{Transport: tr}
	res, _ := client.Do(authReq)
	return res
}

// good
import (
	"crypto/tls"
	"net/http"
)

func doAuthReq(authReq *http.Request) *http.Response {
	tr := &http.Transport{
		TLSClientConfig: &tls.Config{InsecureSkipVerify: false},
	}
	client := &http.Client{Transport: tr}
	res, _ := client.Do(authReq)
	return res
}

1.5 敏感数据保护

1.5.1【必须】敏感信息访问

禁止将敏感信息硬编码在程序中，既可能会将敏感信息暴露给攻击者，也会增加代码管理和维护的难度
使用配置中心系统统一托管密钥等敏感信息

1.5.2【必须】敏感数据输出

只输出必要的最小数据集，避免多余字段暴露引起敏感信息泄露
不能在日志保存密码（包括明文密码和密文密码）、密钥和其它敏感信息
对于必须输出的敏感信息，必须进行合理脱敏展示

// bad
func serve() {
	http.HandleFunc("/register", func(w http.ResponseWriter, r *http.Request) {
		r.ParseForm()
		user := r.Form.Get("user")
		pw := r.Form.Get("password")

		log.Printf("Registering new user %s with password %s.\n", user, pw)
	})
	http.ListenAndServe(":80", nil)
}

// good
func serve1() {
	http.HandleFunc("/register", func(w http.ResponseWriter, r *http.Request) {
		r.ParseForm()
		user := r.Form.Get("user")
		pw := r.Form.Get("password")

		log.Printf("Registering new user %s.\n", user)

		// ...
		use(pw)
	})
	http.ListenAndServe(":80", nil)
}

避免通过GET方法、代码注释、自动填充、缓存等方式泄露敏感信息

1.5.3【必须】敏感数据存储

敏感数据应使用SHA2、RSA等算法进行加密存储
敏感数据应使用独立的存储层，并在访问层开启访问控制
包含敏感信息的临时文件或缓存一旦不再需要应立刻删除

1.5.4【必须】异常处理和日志记录

应合理使用panic、recover、defer处理系统异常，避免出错信息输出到前端

defer func () {
	if r := recover(); r != nil {
		fmt.Println("Recovered in start()")
	}
}()

对外环境禁止开启debug模式，或将程序运行日志输出到前端

// bad
dlv --listen=:2345 --headless=true --api-version=2 debug test.go
// good
dlv debug test.go

1.6 加密解密

1.6.1【必须】不得硬编码密码/密钥

在进行用户登陆，加解密算法等操作时，不得在代码里硬编码密钥或密码，可通过变换算法或者配置等方式设置密码或者密钥。

// bad
const (
	user     = "dbuser"
	password = "s3cretp4ssword"
)

func connect() *sql.DB {
	connStr := fmt.Sprintf("postgres://%s:%s@localhost/pqgotest", user, password)
	db, err := sql.Open("postgres", connStr)
	if err != nil {
		return nil
	}
	return db
}

// bad
var (
	commonkey = []byte("0123456789abcdef")
)

func AesEncrypt(plaintext string) (string, error) {
	block, err := aes.NewCipher(commonkey)
	if err != nil {
		return "", err
	}
}

1.6.2【必须】密钥存储安全

在使用对称密码算法时，需要保护好加密密钥。当算法涉及敏感、业务数据时，可通过非对称算法协商加密密钥。其他较为不敏感的数据加密，可以通过变换算法等方式保护密钥。

1.6.3【推荐】不使用弱密码算法

在使用加密算法时，不建议使用加密强度较弱的算法。

// bad
crypto/des，crypto/md5，crypto/sha1，crypto/rc4等。

// good
crypto/rsa，crypto/aes等。

1.7 正则表达式

1.7.1【推荐】使用regexp进行正则表达式匹配

正则表达式编写不恰当可被用于DoS攻击，造成服务不可用，推荐使用regexp包进行正则表达式匹配。regexp保证了线性时间性能和优雅的失败：对解析器、编译器和执行引擎都进行了内存限制。但regexp不支持以下正则表达式特性，如业务依赖这些特性，则regexp不适合使用。
- 回溯引用Backreferences
- 查看Lookaround

// good
matched, err := regexp.MatchString(`a.b`, "aaxbb")
fmt.Println(matched) // true
fmt.Println(err)     // nil

后台类

1 代码实现类

1.1 输入校验

1.1.1【必须】按类型进行数据校验

所有外部输入的参数，应使用validator进行白名单校验，校验内容包括但不限于数据长度、数据范围、数据类型与格式，校验不通过的应当拒绝

// good
import (
	"fmt"
	"github.com/go-playground/validator/v10"
)

var validate *validator.Validate

func validateVariable() {
	myEmail := "abc@tencent.com"
	errs := validate.Var(myEmail, "required,email")
	if errs != nil {
		fmt.Println(errs)
		return
		//停止执行
	}
	// 验证通过，继续执行
	...
}

func main() {
	validate = validator.New()
	validateVariable()
}

无法通过白名单校验的应使用html.EscapeString、text/template或bluemonday对<, >, &, ',"等字符进行过滤或编码

import (
	"text/template"
)

// TestHTMLEscapeString HTML特殊字符转义
func main(inputValue string) string {
	escapedResult := template.HTMLEscapeString(inputValue)
	return escapedResult
}

1.2 SQL操作

1.2.1【必须】SQL语句默认使用预编译并绑定变量

使用database/sql的prepare、Query或使用GORM等ORM执行SQL操作

import (
	"github.com/jinzhu/gorm"
	_ "github.com/jinzhu/gorm/dialects/sqlite"
)

type Product struct {
	gorm.Model
	Code  string
	Price uint
}

...
var product Product
...
db.First(&product, 1)

使用参数化查询，禁止拼接SQL语句，另外对于传入参数用于order by或表名的需要通过校验

// bad
import (
	"database/sql"
	"fmt"
	"net/http"
)

func handler(db *sql.DB, req *http.Request) {
	q := fmt.Sprintf("SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='%s' ORDER BY PRICE",
		req.URL.Query()["category"])
	db.Query(q)
}

// good
func handlerGood(db *sql.DB, req *http.Request) {
	// 使用?占位符
	q := "SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='?' ORDER BY PRICE"
	db.Query(q, req.URL.Query()["category"])
}

1.3 网络请求

1.3.1【必须】资源请求过滤验证

使用"net/http"下的方法http.Get(url)、http.Post(url, contentType, body)、http.Head(url)、http.PostForm(url, data)、http.Do(req)时，如变量值外部可控（指从参数中动态获取），应对请求目标进行严格的安全校验。
如请求资源域名归属固定的范围，如只允许a.qq.com和b.qq.com，应做白名单限制。如不适用白名单，则推荐的校验逻辑步骤是：
- 第 1 步、只允许HTTP或HTTPS协议
- 第 2 步、解析目标URL，获取其HOST
- 第 3 步、解析HOST，获取HOST指向的IP地址转换成Long型
- 第 4 步、检查IP地址是否为内网IP，网段有：
```
// 以RFC定义的专有网络为例，如有自定义私有网段亦应加入禁止访问列表。
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.0/8
```
- 第 5 步、请求URL
- 第 6 步、如有跳转，跳转后执行1，否则绑定经校验的ip和域名，对URL发起请求
官方库encoding/xml不支持外部实体引用，使用该库可避免xxe漏洞

import (
	"encoding/xml"
	"fmt"
	"os"
)

func main() {
	type Person struct {
		XMLName  xml.Name `xml:"person"`
		Id       int      `xml:"id,attr"`
		UserName string   `xml:"name>first"`
		Comment  string   `xml:",comment"`
	}

	v := &Person{Id: 13, UserName: "John"}
	v.Comment = " Need more details. "

	enc := xml.NewEncoder(os.Stdout)
	enc.Indent("  ", "    ")
	if err := enc.Encode(v); err != nil {
		fmt.Printf("error: %v\n", err)
	}

}

1.4 服务器端渲染

1.4.1【必须】模板渲染过滤验证

使用text/template或者html/template渲染模板时禁止将外部输入参数引入模板，或仅允许引入白名单内字符。

// bad
func handler(w http.ResponseWriter, r *http.Request) {
	r.ParseForm()
	x := r.Form.Get("name")

	var tmpl = `
    
        First name:

    
    
    ` + x + ` 
`

	t := template.New("main")
	t, _ = t.Parse(tmpl)
	t.Execute(w, "Hello")
}

// good
import (
	"fmt"
	"github.com/go-playground/validator/v10"
)

var validate *validator.Validate
validate = validator.New()

func validateVariable(val) {
	errs := validate.Var(val, "gte=1,lte=100") // 限制必须是1-100的正整数
	if errs != nil {
		fmt.Println(errs)
		return false
	}
	return true
}

func handler(w http.ResponseWriter, r *http.Request) {
	r.ParseForm()
	x := r.Form.Get("name")

	if validateVariable(x) {
		var tmpl = `
            
            First name:

            
            
            ` + x + ` 
`
		t := template.New("main")
		t, _ = t.Parse(tmpl)
		t.Execute(w, "Hello")
	} else {
		// ...
	}
}

1.5 Web跨域

1.5.1【必须】跨域资源共享CORS限制请求来源

CORS请求保护不当可导致敏感信息泄漏，因此应当严格设置Access-Control-Allow-Origin使用同源策略进行保护。

// good
c := cors.New(cors.Options{
	AllowedOrigins:   []string{"http://qq.com", "https://qq.com"},
	AllowCredentials: true,
	Debug:            false,
})

// 引入中间件
handler = c.Handler(handler)

1.6 响应输出

1.6.1 【必须】设置正确的HTTP响应包类型

响应头Content-Type与实际响应内容，应保持一致。如：API响应数据类型是json，则响应头使用application/json；若为xml，则设置为text/xml。

1.6.2 【必须】添加安全响应头

所有接口、页面，添加响应头 X-Content-Type-Options: nosniff。
所有接口、页面，添加响应头X-Frame-Options 。按需合理设置其允许范围，包括：DENY、SAMEORIGIN、ALLOW-FROM origin。用法参考：MDN文档

1.6.3【必须】外部输入拼接到HTTP响应头中需进行过滤

应尽量避免外部可控参数拼接到HTTP响应头中，如业务需要则需要过滤掉\r、\n等换行符，或者拒绝携带换行符号的外部输入。

1.6.4【必须】外部输入拼接到response页面前进行编码处理

直出html页面或使用模板生成html页面的，推荐使用text/template自动编码，或者使用html.EscapeString或text/template对<, >, &, ',"等字符进行编码。

import (
	"html/template"
)

func outtemplate(w http.ResponseWriter, r *http.Request) {
	param1 := r.URL.Query().Get("param1")
	tmpl := template.New("hello")
	tmpl, _ = tmpl.Parse(`{{define "T"}}{{.}}{{end}}`)
	tmpl.ExecuteTemplate(w, "T", param1)
}

1.7 会话管理

1.7.1【必须】安全维护session信息

用户登录时应重新生成session，退出登录后应清理session。

import (
	"github.com/gorilla/handlers"
	"github.com/gorilla/mux"
	"net/http"
)

// 创建cookie
func setToken(res http.ResponseWriter, req *http.Request) {
	expireToken := time.Now().Add(time.Minute * 30).Unix()
	expireCookie := time.Now().Add(time.Minute * 30)

	//...

	cookie := http.Cookie{
		Name:     "Auth",
		Value:    signedToken,
		Expires:  expireCookie, // 过期失效
		HttpOnly: true,
		Path:     "/",
		Domain:   "127.0.0.1",
		Secure:   true,
	}

	http.SetCookie(res, &cookie)
	http.Redirect(res, req, "/profile", 307)
}

// 删除cookie
func logout(res http.ResponseWriter, req *http.Request) {
	deleteCookie := http.Cookie{
		Name:    "Auth",
		Value:   "none",
		Expires: time.Now(),
	}
	http.SetCookie(res, &deleteCookie)
	return
}

1.7.2【必须】CSRF防护

涉及系统敏感操作或可读取敏感信息的接口应校验Referer或添加csrf_token。

// good
import (
	"github.com/gorilla/csrf"
	"github.com/gorilla/mux"
	"net/http"
)

func main() {
	r := mux.NewRouter()
	r.HandleFunc("/signup", ShowSignupForm)
	r.HandleFunc("/signup/post", SubmitSignupForm)
	// 使用csrf_token验证
	http.ListenAndServe(":8000",
		csrf.Protect([]byte("32-byte-long-auth-key"))(r))
}

1.8 访问控制

1.8.1【必须】默认鉴权

除非资源完全可对外开放，否则系统默认进行身份认证，使用白名单的方式放开不需要认证的接口或页面。
根据资源的机密程度和用户角色，以最小权限原则，设置不同级别的权限，如完全公开、登录可读、登录可写、特定用户可读、特定用户可写等
涉及用户自身相关的数据的读写必须验证登录态用户身份及其权限，避免越权操作
```
-- 伪代码
select id from table where id=:id and userid=session.userid
```
没有独立账号体系的外网服务使用QQ或微信登录，内网服务使用统一登录服务登录，其他使用账号密码登录的服务需要增加验证码等二次验证

1.9 并发保护

1.9.1【必须】禁止在闭包中直接调用循环变量

在循环中启动协程，当协程中使用到了循环的索引值，由于多个协程同时使用同一个变量会产生数据竞争，造成执行结果异常。

// bad
func main() {
	runtime.GOMAXPROCS(runtime.NumCPU())
	var group sync.WaitGroup

	for i := 0; i < 5; i++ {
		group.Add(1)
		go func() {
			defer group.Done()
			fmt.Printf("%-2d", i) // 这里打印的i不是所期望的
		}()
	}
	group.Wait()
}

// good
func main() {
	runtime.GOMAXPROCS(runtime.NumCPU())
	var group sync.WaitGroup

	for i := 0; i < 5; i++ {
		group.Add(1)
		go func(j int) {
			defer func() {
				if r := recover(); r != nil {
					fmt.Println("Recovered in start()")
				}
				group.Done()
			}()
			fmt.Printf("%-2d", j) // 闭包内部使用局部变量
		}(i) // 把循环变量显式地传给协程
	}
	group.Wait()
}

1.9.2【必须】禁止并发写map

并发写map容易造成程序崩溃并异常退出，建议加锁保护

// bad
func main() {
	m := make(map[int]int)
	// 并发读写
	go func() {
		for {
			_ = m[1]
		}
	}()
	go func() {
		for {
			m[2] = 1
		}
	}()
	select {}
}

1.9.3【必须】确保并发安全

敏感操作如果未作并发安全限制，可导致数据读写异常，造成业务逻辑限制被绕过。可通过同步锁或者原子操作进行防护。

通过同步锁共享内存

// good
var count int

func Count(lock *sync.Mutex) {
	lock.Lock() // 加写锁
	count++
	fmt.Println(count)
	lock.Unlock() // 解写锁，任何一个Lock()或RLock()均需要保证对应有Unlock()或RUnlock()
}

func main() {
	lock := &sync.Mutex{}
	for i := 0; i < 10; i++ {
		go Count(lock) // 传递指针是为了防止函数内的锁和调用锁不一致
	}
	for {
		lock.Lock()
		c := count
		lock.Unlock()
		runtime.Gosched() // 交出时间片给协程
		if c > 10 {
			break
		}
	}
}

使用sync/atomic执行原子操作

// good
import (
	"sync"
	"sync/atomic"
)

func main() {
	type Map map[string]string
	var m atomic.Value
	m.Store(make(Map))
	var mu sync.Mutex // used only by writers
	read := func(key string) (val string) {
		m1 := m.Load().(Map)
		return m1[key]
	}
	insert := func(key, val string) {
		mu.Lock() // 与潜在写入同步
		defer mu.Unlock()
		m1 := m.Load().(Map) // 导入struct当前数据
		m2 := make(Map)      // 创建新值
		for k, v := range m1 {
			m2[k] = v
		}
		m2[key] = val
		m.Store(m2) // 用新的替代当前对象
	}
	_, _ = read, insert
}

Go 使用的 plan9 汇编语言初探

Sun, 04 Apr 2021 20:30:20 +0000

plan9 汇编既不同于 Intel-x86 家族的汇编，也不与 AT&T 标准相同，作者是 unix 操作系统的同一批人，bell 实验室所开发的，其实 plan9 是一个操作系统，我们主要关注构建它的汇编语言。

Go 语言早在 1.5 版本就实现了自举，即使用 Go 语言去写 Go 语言。Go 的底层实现是使用 plan9 汇编完成的，并不是我们常见的 Intel 家族汇编，它与其他的汇编有几个不同点，在下文中一边比较一边介绍。

伪寄存器

plan9 抽象了 4 种伪寄存器：

FP（Frame Pointer），帧指针，快速访问函数的参数和返回值。
SP（Stack Pointer），栈指针，指向栈顶。
SB（Static base pointer），静态基址，全局变量。
PC（Program Counter），其实就是 IP（Instruction Pointer）的别名，指向下一条指令的地址。jmp等跳转指令还有分支控制等原理就是通过修改这个值。在 8086 机里等价于 CS:IP。

其实就是对 CPU 的重新抽象，这个抽象结构与具体的 CPU 结构无关。

它们之间的具体关系如下图：

与x86汇编的差异

许多人之前广泛了解的汇编可能是 AT&T 格式或者传统 Intel-x86 格式，AT&T 规范与 x86 有许多不同，而 plan9 与 AT&T 有许多相似的地方，比如操作数顺序许多是相同的，但 不完全等价。还是需要我们重新学习，这里列举一些常见区别。

Mnemonic | Go operands           | AT&T operands
================================================
BOUNDW   | m16&16, r16           | r16, m16&16
BOUNDL   | m32&32, r32           | r32, m32&32
CMPB     | AL, imm8              | imm8, AL
CMPW     | AX, imm16             | imm16, AX
CMPL     | EAX, imm32            | imm32, EAX
CMPQ     | RAX, imm32            | imm32, RAX
CMPW     | r/m16, imm16          | imm16, r/m16
CMPW     | r/m16, imm8           | imm8, r/m16
CMPW     | r/m16, r16            | r16, r/m16
CMPL     | r/m32, imm32          | imm32, r/m32
CMPL     | r/m32, imm8           | imm8, r/m32
CMPL     | r/m32, r32            | r32, r/m32
CMPQ     | r/m64, imm32          | imm32, r/m64
CMPQ     | r/m64, imm8           | imm8, r/m64
CMPQ     | r/m64, r64            | r64, r/m64
CMPB     | r/m8, imm8            | imm8, r/m8
CMPB     | r/m8, imm8            | imm8, r/m8
CMPB     | r/m8, r8              | r8, r/m8
CMPB     | r/m8, r8              | r8, r/m8
CMPW     | r16, r/m16            | r/m16, r16
CMPL     | r32, r/m32            | r/m32, r32
CMPQ     | r64, r/m64            | r/m64, r64
CMPB     | r8, r/m8              | r/m8, r8
CMPB     | r8, r/m8              | r/m8, r8
CMPPD    | imm8, xmm1, xmm2/m128 | imm8, xmm2/m128, xmm1
CMPPS    | imm8, xmm1, xmm2/m128 | imm8, xmm2/m128, xmm1
CMPSD    | imm8, xmm1, xmm2/m64  | imm8, xmm2/m64, xmm1
CMPSS    | imm8, xmm1, xmm2/m32  | imm8, xmm2/m32, xmm1
ENTER    | 0, imm16              | imm16, 0
ENTER    | 1, imm16              | imm16, 1

操作数顺序不同

在 x86 中，一些常见指令是这样的：

MOV EAX, 10  ;EAX=10
MOV AH, [BL] ;AH=*BL

而在 plan9 中操作数的顺序会相反：

MOVL a+0(FP), AX  ;AX=a 
MOVB BX, AX    ;AX=BX

不止这些，还有 LEA ADD SUB IMUL等等也都满足。

操作数大小表示法不同

在 x86 中，表示大小通过直接区分操作数，比如 AX 寄存器的高 8 位就是 AH ，低 8 位就叫 AL.。而 plan9 中通过不同操作码来区分：

MOVB $0x10, AX  ;1B, Byte
MOVW $-10, DI  ;2B, 1Word=2Byte
MOVL $0, SP   ;4B, Double Word
MOVQ $1, DX   ;8B, Quatury Word

寄存器

寄存器分为 实寄存器（real register）和伪寄存器（pseudo register） ，前者在 CPU 内部，属于 CPU 的固件，作为与 CPU 直接产生信息交换的单位，具体种类与架构有关，可以通过 dlv 工具查看：

示例程序的机器为 AMD64，也就是 x86-64。不同的机器可能会因为 CPU 的不同而不同。

(dlv) regs                                       
   Rip = 0x00007ff90ed00771                      
   Rsp = 0x000000cfd45ff260                      
   Rax = 0x0000000000000000                      
   Rbx = 0x0000000000000010                      
   Rcx = 0x00007ff90eccd2c4                      
   Rdx = 0x0000000000000000                      
   Rsi = 0x00007ff90ed61a80                      
   Rdi = 0x000000cfd4237000                      
   Rbp = 0x0000000000000000                      
    R8 = 0x000000cfd45ff258                      
    R9 = 0x0000000000000000                      
   R10 = 0x0000000000000000                      
   R11 = 0x0000000000000246                      
   R12 = 0x0000000000000040                      
   R13 = 0x0000000000000000                      
   R14 = 0x00007ff90ed548f0                      
   R15 = 0x00000254e7900000                      
Rflags = 0x0000000000000246     [PF ZF IF IOPL=0]
    Cs = 0x0000000000000033                      
    Fs = 0x0000000000000053                      
    Gs = 0x000000000000002b

后者是应用层抽象出来的概念，实际并不存在，目的是为了更方便地写汇编。

由于历史原因，x86 平台要保证向后兼容，要求在 64 位机上要能够运行 32、16、8位程序。解决方法是通过给寄存器加前缀实现的。

AH/AL -> AX -> EAX -> RAX
  8      16     32     64

除此之外，还有这些对应关系

X64	rax	rbx	rcx	rdx	rdi	rsi	rbp	rsp	r8	r9	r10	r11	r12	r13	r14	rip
Plan9	AX	BX	CX	DX	DI	SI	BP	SP	R8	R9	R10	R11	R12	R13	R14	PC

伪寄存器

为了方便编程，plan9 还引入了 4 个伪寄存器，SP FP SB PC。想当年面试的时候（其实就是去年，我张口就来引入这四个是为了增加性能（猜的，回头想想还真是离谱。

这 4 个有不同的作用，其中伪SP寄存器还与真SP寄存器重名了，就更容易让初学者懵逼了，这里放个曹大的图就明白了。

这个图里有一点歧义，红色部分是栈，黄色是堆，图中的关系是堆在上面，而实际堆是向上增长的。

另外还有一点，这张图里没有标明实寄存器BP 的位置，BP 是栈基地址。

函数调用

这里拿一个简单的函数嵌套调用代码，来举例说明它们之间的具体位置关系和实现原理：

func upper() {
    r0, r1 := f0(arg0, arg1)
}

func f0(arg0, arg1 int) (ret0, ret1 int) {
    r0 := arg0 - arg1
    r1 := arg0 + arg1
    r1 = f1(r0)
    return r0, r1
}

func f1(arg0 int) (ret0 int) {
    return 1 + arg0
}

栈帧

函数实现嵌套调用依靠的数据结构就是栈，上面这个程序它的调用栈帧如下：

       
                    +------------+ <----------+
                    |    ....    |            |
                    +------------+            |
                    |    Ret1    |            |
                    +------------+            |
                    |    Ret0    |
                    +------------+      upper call stack
                    |    Arg1    |
                    +------------+            |
                    |    Arg0    |            |
                    +------------+            |
                    |  Ret Addr  |            |
                    +------------+ <----------+
real BP(pseudo SP)  |  upper BP  |            |
------------------> +------------+            |
                    |   Local0   |            |
                    +------------+            |
       real SP      |   Local1   |
  ----------------> +------------+
                    |            |      f0 stack frame
                    |unused space|
                    |            |
                    +------------+            |
                    |    Ret0    |            |
                    +------------+            |
       pseudo FP    |    Arg1    |            |
  ----------------> +------------+            |
                    |  Ret Addr  |            |
                    +------------+ <----------+
                    |Caller f0'BP|
                    +------------+
                    |   Local0   |
                    +------------+
                    |   Local1   |
                    +------------+
                    |    ...     |
                    +------------+

验证

我们使用 FP/real SP/pseudo SP 来验证一下上面的栈帧示意图：

分析一个简单的程序

好了，终于见到「真的汇编代码」了，理论知识差不多了（误

package main

func add(x, y int) (sum int, sub int) {
  z := x + y
  w := x - y
  return z, w
}

func main() {
  c, d := add(2, 3)
}

前置知识

在命令行中执行 go tool compile -S -N -l main.go 查看汇编代码。看之前需要注意两点，

不管使用 go tool compile -S 还是 go tool objdump 来查看汇编代码，都是和实际我们手写 plan9 不同的，不能照搬语法。这两者关于汇编指令的输出也是不同的。当然，十六进制肯定是相同的。
输出的所有 SP 指针无论带不带 symbol 都是实寄存器，而实际上在手写 plan9 时，如果使用了形如 symbol+offset(SP) 的表达则指使用的是伪SP指针，不带则是真SP指针。
而实际手写在使用 FP 寄存器时如果不带 symbol 会直接报错。

变量与常量

函数

"".add STEXT nosplit size=19 args=0x18 locals=0x0 funcid=0x0
        0x0000 00000 (notify.go:7)      TEXT    "".add(SB), NOSPLIT|ABIInternal, $0-24
        0x0000 00000 (notify.go:7)      FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (notify.go:7)      FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0000 00000 (notify.go:8)      MOVQ    "".b+16(SP), AX
        0x0005 00005 (notify.go:8)      MOVQ    "".a+8(SP), CX
        0x000a 00010 (notify.go:8)      ADDQ    CX, AX
        0x000d 00013 (notify.go:8)      MOVQ    AX, "".~r2+24(SP)
        0x0012 00018 (notify.go:8)      RET

先看第一行内容：

"".add STEXT nosplit size=19 args=0x18 locals=0x0 funcid=0x0

内容虽然多，但是非常好理解，不同数值均给出了名称，但是更标准的表示法一般是这样：

TEXT runtime∕internal∕atomic·Cas(SB),NOSPLIT,$0-17

双引号里和 runtime/internal/atomic 都是函数名，可以省略，后面紧跟函数名。TEXT 是区段名。SB 是基于伪寄存器 SB 进行偏移，比如：

+4(SB)
a+8(SB)

一个是在 SB 寄存器起始地址上正向偏移 4 个字节，一个是从 SB 的 a 变量开始偏移 4 个字节。

由于 Go 语言函数的调用栈帧默认是动态伸缩的，初始大小只有 2KB，你可以使用 指令 来控制这个行为：

//go:nosplit
func str2slc(s string) []byte {
    ...
}

这条指令可以禁止扩容检测，这样做一定程度上可以增加效率。而汇编代码里的 nosplit 是编译器帮我们做的优化。除此之外，还有 WRAPPER、noinline 等许多指令，都是用来指导编译器的工作，例如禁用内联，禁止逃逸，禁止逃逸分析等等，具体及更多信息可以在官方文档 golang.org/cmd/compile 查看。

$0-17 的 0 是函数栈帧大小，指函数内的局部变量总大小，这个值包括准备子函数参数的开销。17 是参数大小，’-’ 不是减号，只是连接符，不要想当然认为栈向下增长所以是做减法（不过好像问题也不大

~~需要注意的是，如果没有 nosplit，则必须给出参数大小，而不能直接 $x，因为 Go 语言编译器已无法根据函数签名进行占用空间大小的推导。~~

所以，最终定义函数的标准语法如下：

TEXT symbol(SB), [flags,] $framesize[-argsize]

手写来练习一下吧

看了这么多，来手写一个简单的 plan9 汇编程序练习一下。

目标：实现一个求整型切片元素和的函数，函数签名为：func addSliceInt(slc []int) int。举个例子，如果 slc := []{1,2,3,4}，那么返回 10.

总结

plan9 是一个操作系统，对应一套汇编语法，被称为 plan9 汇编，与 AT&T 规范非常相似，也不完全一样。与传统 x86 汇编差异较大。

plan9 重新定义了 4 个伪寄存器来方便编程，函数嵌套调用的核心就是依靠栈的先进先出特性，在调用前来保护 Caller 的执行现场，并在 Callee 执行完返回后恢复现场，从而继续执行。

没有 push，pop 等栈操作，栈的增缩是通过对 sp 栈顶寄存器的加减实现的，例如 +8（sp）
操作数的大小不是通过区分操作码来实现的，而是通过操作码的后缀实现，例如复制 ax 寄存器低 1 字节到第二字节，在 x86 汇编中是通过 mov ah,al，而在 plan9 中则是通过 movb al,ah
- b w d q分别代表1 2 4 8 Byte，含义是byte，word，double word，quatury。
操作数在第一个参数，结果放在第二个参数，与intel汇编相反，具体看第二条

我们学习 plan9 汇编其实也并没有太大困难，前期在学习时也未必要看懂全部的汇编代码，可先学习大概思路，再深入了解即可。

但是为什么 plan9 不与 x86 系兼容呢，而要单独开发一套自己的语法呢，我看了不少人的解释，貌似是因为 unix 团队是学院派，特立独行，也不屑于商业化（就是玩

Go unsafe.Pointer、uintptr、Pointer 之间的区别与联系

Sun, 14 Mar 2021 13:35:20 +0000

前几天见到了一个问题：

uintptr与 unsafe.Pointer 有什么区别？

你可能曾经看到过类似这样的代码：

type T struct {
    a uint8
    b bool
    c string
}

t := T{a: 1, b: true, c: "goooo"}
Tc := *(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&a)) + unsafe.Offsetof(T{}.c)))
fmt.Println(Tc)

这一行代码看似实现的功能非常复杂，其实它就是等价于：

fmt.Println(t.c)

从某种意义上来说，这好像没什么用（确实没啥作用…），那你再看一段代码：

//go:nosplit
func Bytes2String(bs []byte) string {
    return *(*string)(unsafe.Pointer(&bs))
}

//go:nosplit
func String2Bytes(s string) []byte {
    ss := *[2]uintptr(unsafe.Pointer(&s))
    b := [3]uintptr{ss[0], ss[1], ss[1]}
    return *(*[]byte)(unsafe.Pointer(&b))
}

这两个函数实现了 []Byte 与 string 的互转，并且不需要申请任何内存，因为他们共享底层数据空间。

函数前的类似注释的一行是一些指令，用来指示编译器进行一些用户的行为，Go 中的栈帧是可以根据需要动态增长的，一开始只有 2048Byte，是固定在源码中的。而 go:nosplit 就是表明函数栈空间无需动态增长，这在一定程度上增加了效率，但是如果你申请了过量的空间，就会导致程序因为爆栈而 panic。

这段代码通过 unsafe.Pointer 类型实现了从 float64 强转 uint64 的效果，出自标准库。

func Float64bits(f float64) uint64 {
    return *(*uint64)(unsafe.Pointer(&f))
}

unsafe包

Go 语言本身由于类型系统的原因，不支持指针的运算操作，对于指针的使用进行了极大的限制，不像 C/C++ 语言那样对指针 “为所欲为”，也不像 Java 语言中那样根本不提供指针，采取了一种折中方案，只支持常见的取址（&），取值（*）操作。但是为了有些场合的需要，还是提供了一个用来直接无视类型系统而直接操作的特性，这便是 unsafe 包提供的能力。

unsafe 包开放了一个类型，三个函数，分别是：

Pointer ，任意指针类型，类似于 C/C++ 语言中的 void* 类型
Alignof(x ArbitraryType) uintptr 函数，计算变量内存对齐边界大小
Sizeof(x ArbitraryType) uintptr 函数，计算该类型所占用内存大小，不包含底层数据大小
Offsetof(x ArbitraryType) uintptr 函数，计算该变量相对于结构体首地址的地址偏移

看源码过程中可能会看到 ArbitraryType 类型，而 Pointer 就是 ArbitraryType 类型，不必疑惑，这个类型没有任何实际意义，仅仅代表了它可以是任意 Go 语言类型，不是 unsafe 包的组成部分。

Go 语言类型系统的限制，不允许进行指针运算，比如：

a := 1
pa := &a
pa++

编译器无法通过这种写法，会报不支持这种运算的错误：

# command-line-arguments
.\notify.go:17:5: invalid operation: pa++ (non-numeric type *int)

这 “一类型，三函数” 所提供的能力就是直接无视这个限制，直接进行地址运算，下面详细介绍这些能力。

一类型Pointer

Pointer 类型提供了 uintptr 与类型指针之间的转换中介，要想将任意指针类型 *p 转为 uintptr 来进行指针运算，需要先转换为 Pointer 类型，再转换为 uintptr 类型。

类型介绍

unsafe.Pointer 类型的定义非常简单，就是一个任意类型的指针表示：

type ArbitraryType int
type Pointer *ArbitraryType

自定义了一个命名类型 ArbitraryType，这个类型并没有什么实际含义，只是表示任意类型，在代码文档中使用。如果没有这个类型，那么 Sizeof 等函数的参数就是 int 类型，会让人费解。所以正如字面意思，Pointer 的含义就是 “任意类型的指针”。

使用注意

除了上图描述的这个类型间转换规则外，还需要遵循几个固定的规则。

uintptr变量无法保持对变量的引用

你不能这么做：

var i int = 1
up := uintptr(unsafe.Pointer(&i))
// after 1000 years...
Println(i) // maybe panic!

uintptr 可以用来进行指针运算，实际上就是一个非常大的无符号整数类型，可以表示所有地址空间。上述代码可能会 panic 的原因是 i 变量可能会被 Garbage Collector（gc）回收。一般这个 uintptr 类型只作为中间值参与运算。

使用案例

go slice 的创建是通过 makeslice 创建，返回值是一个结构体：

func makeslice(et *_type, len, cap int) slice

我们可以通过以下两种方式获取切片的长度：

s := make([]int, 8, 8)
Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + uintptr(8)))) // 8
Println(len(s)) // 8

把 uintptr(8) 改为 uintptr(16) 就可以获取到容量了。

如果我们想获取 map 的大小，需要有一点小小的改变，因为 map 的创建是通过 makemap 函数：

func makemap(t *maptype, hint int64, h *hmap, bucket unsafe.Pointer) *hmap

该返回的是一个指针，由于再次取地址，是二级指针，所以我们稍稍修改一下代码：

mm := make(map[int]int, 8)
Println(**(**int)(unsafe.Pointer(&mm)))  // 8

三函数Alignof、Sizeof和Offsetof

看了上面的内容，可能会有一个疑问，这有什么用呢？不是有更优的 “常规” 解法吗？

我想说的是，除了 zero-copy 来转换 slice 与 string 这个例子之外，还有一个场景。

如果结构体成员私有，包外如何访问？你不能通过常规的运算符 ‘.’ 来访问到私有字段，就要借助 unsafe 包了。通过 unsafe.Sizeof 函数计算偏移字段的大小和，直接获取到目标字段的地址偏移：

package a
type T struct {
    a int
    b bool
    c byte
}

package b
t := a.T{ a: 1, b: true, c: 2 }
tc := *(*byte)(unsafe.Pointer)(uintptr(unsafe.Pointer(&t)) + unsafe.Sizeof(0) + unsafe.Sizeof(true))
Println(tc) // 2

总结

Go 语言中和了 C/C++ 和 Java 语言对指针提供的能力，有效地解决了指针滥用导致内存泄露、非法访问等安全问题。通过静态语言的严格类型系统限制了一些内存操作，也提供了一个不安全但 “炫酷” 的 unsafe 包，标准库的源码许多都使用了 unsafe 包所提供了能力，高效简洁，让我们仿佛在看 C 系语言源码。这也不难理解，Go 语言的创始人之一正是 C 语言的创造者之一，许多设计思想优秀且独树一帜。

不过之所以命名为 unsafe，也是因为可以直接绕过类型系统直接操作底层内存，会带来一定的安全问题，与 GC 的工作 “冲突”，所以需要我们谨慎使用。

深入理解 Go channel

Thu, 25 Feb 2021 19:35:20 +0000

Go 语言的 Channel 关键字是实现其原生并发编程的关键组成，你可能听说过 “不要通过共享内存的方式通信，要通过通信的方式共享内存”，这句话正是针对 Channel 说的。

Go 语言倡导通过通信的方式共享内存，也就是减少锁的使用，尽量都通过 Channel 来进行协程间通信。

其实这被称为一种并发模型名为 CSP（Communicating Sequential Processes），即通信顺序进程。

两个实体 goroutine 通过 Channel 通信，收发消息。

数据结构

Channel 是一种 带锁环状队列，运行时结构定义在 runtime/chan.hchan ，代码也比较容易理解。

type hchan struct {
	qcount   uint           // 队列中元素数量
	dataqsiz uint           // 环形队列总大小
	buf      unsafe.Pointer // 底层数组指针
	elemsize uint16			// 元素大小
	closed   uint32			// 是否已关闭
	elemtype *_type 		// 元素类型
	sendx    uint   // 发送端下标
	recvx    uint   // 接收端下标
	recvq    waitq  // 接收端等待队列
	sendq    waitq  // 发送端等待队列

	// 保护 hchan 并发访问的字段
	lock mutex
}

type waitq struct {
	first *sudog	// 等待队列链表的头节点
	last  *sudog	// 尾节点
}

通过两个指针指向发送端和接收端接下来的操作位置，结合锁机制完成数据操作，这是很容易想到的并发处理方式。runtime/chan.waiq 是阻塞等待 goroutine 的双向链表，每一个节点是一个封装了的 goroutine，被命名为 sudog，定义在 runtime/runtime2.go 。

type sudog struct {
	g *g

	next *sudog
	prev *sudog
	elem unsafe.Pointer // data element (may point to stack)
	...

}

next 和 prev 就是指向前后节点的指针，并且包裹了一个 goroutine 结构。

深入理解 Go string 与 slice

Mon, 15 Feb 2021 23:35:20 +0000

数据结构

我们先通过标准库源码来简单看一下。string 和 slice 的数据结构都定义在 reflect/value.go 中，分别对应着 StringHeader 和 SliceHeader 。

type StringHeader struct {
	Data uintptr
	Len  int
}

type SliceHeader struct {
	Data uintptr
	Len  int
	Cap  int
}

定义非常简单，Data 表示底层数据的地址，Len 表示长度，Cap 表示容量。容量评估了当前切片最多能容纳多少字节元素，而长度表示当前已经存储多少个字节了，切片只是对底层数据的引用：

[图片]

字符串就是字符的数组，我们先来看个小程序的例子：

package main

func main() {
	s := "abc"
	println(s)
}

我们执行 go tool compile -S main.go 使用自带工具包查看汇编代码，可以看到有这样一段信息：

...
go.string."abc" SRODATA dupok size=3
        0x0000 61 62 63    abc
...

很直观的可以看到字符串被分配到了 RODATA 区段，也就是只读区段（Read Only），也就是说 Go 字符串是不可修改的。

深入理解 Go defer 版本差异与底层特性

Mon, 25 Jan 2021 23:35:20 +0000

defer 简介

defer 的作用是使某个/某些执行延时执行，常用在资源使用后的释放等场景，例如：

func DbInit() (sql.DB, error) {
    db, err := sql.Open()
    if err != nil {
        return nil, err
    }
    defer db.Close()
    ...
}

defer 有一些熟知的特性：

“先进后出”，也就是说如果使用了多个 defer，最先使用 的 defer 后的函数体 最后执行。
一定会执行，即 panic 后依然有效。
执行体参数在注册 defer 时确定。
…

我们先来看看为什么。

结构定义

先来看看标准库中 runtime/runtime2.defer 的定义。

type _defer struct {
	siz     int32	// 函数参数和返回值的大小
	started bool
	heap    bool	// 是否分配在堆上

	openDefer bool	// 是否经过开放编码的优化
	sp        uintptr  // defer函数体的栈顶指针
	pc        uintptr  // 下一条指令地址
	fn        *funcval // 执行函数地址，如果是开放编码可以为空
	_panic    *_panic  // 与之相关的panic链表
	link      *_defer	// defer链表

	...
}

除堆分配和开放编码相关字段之外，其余字段很容易理解。这两个特性是在 1.13 与 1.14 引入的，重点解决 defer 性能问题，放在下文。还有一些字段是关于 gc 的，理解较为复杂，暂不讨论。

除此之外，有两个字段比较重要，link 与 _panic。前者将注册的许多 defer 串成链表，在执行的时候按预先定义的顺序访问，先恢复执行体函数所需的栈信息等操作，跳转到函数地址处执行；后者将 defer 与 panic 进行关联，确保发生 panic 后按序执行所有注册过的 defer 函数。

编译阶段会把 defer 关键字分为三种状态，分别是开放编码，栈分配，堆分配。

func (s *state) stmt(n *Node) {
    ...
    switch n.Op {
        ...
        case ODEFER:
			...
			if s.hasOpenDefers {
				s.openDeferRecord(n.Left)	// 开放编码
			} else {
				d := callDefer	// 堆分配
				if n.Esc == EscNever {
					d = callDeferStack	// 栈分配
				}
				s.callResult(n.Left, d)
			}
        ...
    }
    ...
}

早起的 Go （1.13 之前）会把 defer 所需内存全部分配在堆上，性能较差，在 1.13 时通过调用分析可选择分配在栈上以增加性能，提升了大约 30%，1.14 又增加了开放编码方式，使 defer 的调用损耗可以忽略不计（<10ms）。

现象背后的原因

先讨论表象背后的底层原理，即

版本差异

总结

深入理解 Go map

Fri, 22 Jan 2021 23:35:20 +0000

哈希表

几乎所有语言都有哈希表这个数据结构，能够在平均 O(1)，最差 O(n) 的时间复杂度内增删改查元素，Go 语言哈希表的精妙设计使得它几乎不会出现 O(n) 的糟糕情况。这篇文章我就带你从使用到底层由浅入深地探究 Go map 的奥秘，一起作一个不只是会用的 ”大神“。

问题来源于实际，我们先看看这些实际问题：

声明。当我使用 :=，var，make，甚至 new 声明 map 的时候，编译器帮我们做了什么事情，它们有什么区别？
增删改查。使用数组+链表的情况下如何设计才能避免 O(n) 的最差情况？
注意事项。map 的键有什么要求？map 是值类型还是引用类型，函数传参时会有上层影响吗？是并发安全的吗？

还有一个常识是 Go map 的 遍历是随机的，即多次遍历输出的结果不同，这个的原因会在后面提到。

设计方式/数据结构

Go map 实现哈希表使用的是 数组+链表 的形式，也就是使用链地址法解决的哈希冲突。这种方式桶的大小和元素个数之间没有关系，另外还有开放定址法，这是个宽泛的名字，具体包含线性探测法，再哈希法，平方探测法等等。

为了降低 map 操作的时间复杂度，引入了一个负载因子的概念，这个概念在其他实现哈希表这个数据结构的语言里也都有，比如 python 中这个值被定义为 2/3，Java 中是 0.75，这个值评估了哈希表里 实际上最好只存 多少比例的元素，而不是一直等到满载再处理，因为多到一定程度效率可能就低了。在 Go 语言里这个值被定义为 6.5，即每个桶里最多存 6.5 个，包括溢出桶。

当我们在 Go 语言中声明一个 map 的时候，实际上就是创建了一个 hmap 的结构体，它定义在 runtime/map.go 文件下，这个结构体包含了许多信息：map 的大小，桶数量、地址，溢出桶数量、地址等等。哈希表就是实现一个映射关系，给出自变量 x，能够通过平均 O(1) 的时间复杂度方法找到这个元素所对应的因变量 y=f(x) 来对它进行操作。

type hmap struct {
    count     int 		// map的大小，len()的结果就是这个字段值
	flags     uint8		// map的状态，有四个
	B         uint8  	// 桶数量的log_2对数，如B=5，桶数量就是2^5=32
	noverflow uint16 	// 溢出桶的数量
	hash0     uint32 	// 哈希种子

	buckets    unsafe.Pointer // 桶数组的底层地址
	oldbuckets unsafe.Pointer // 旧桶数组的底层地址
	nevacuate  uintptr        // 迁移进度

	extra *mapextra // 溢出桶
}

type mapextra struct {
	overflow    *[]*bmap
	oldoverflow *[]*bmap

	// 指向下一个空闲溢出桶
	nextOverflow *bmap
}

需要注意的是，如果 map 的键值都不包含指针并且是内联的，那么我们就会标注 map 为 ”不含指针类型“，这样就可以避免 GC 扫描 map，从而避免在 map 在过大时由于指针过多造成的 GC 扫描对象过多而缓慢的问题。所以将所有关于溢出桶的指针都放在了 extra 字段中。mapextra 字段保存了与溢出桶相关的信息，overflow 指向当前桶 hmap.buckets 的溢出桶，oldoverflow 指向旧桶 hmap.oldbuckets 的溢出桶。

真正存储数据的地方是 bmap，map 有 2^B 个 bmap，但是每个 bmap 只能存储 8 个键值对，多出来的就要找到一个溢出桶放进去，每个桶的数据结构都是一样的，bmap 结构只有 tophash 字段是因为 map 的 key 和 value 是需要 在编译时计算确定，所以需要在编译时动态构造桶结构。唯一的 tophash 字段是键值经过哈希函数计算后的值高八位。

type bmap struct {
	tophash [bucketCnt]uint8
}

此外，动态运行时构造的 key 和 value 键值对并没有按照 key1/value1、key2/value2、…、keyN/valueN 的方式存储，而是如图形式，是为了避免因为字节对齐造成的内存浪费，也是因为 CPU 从内存中读取数据是每次读取固定大小的块（因为数据总线条数固定），这块内存也并不是连续的，这里不展开说了，总之，如果采用 key1/value1、key2/value2、…、keyN/valueN 的方式，如果 map 是 map[int64]int8 的时候，每个键值对就会由于内存不对齐造成 7 字节的内存浪费，其实也并不一定浪费，现在很多 CPU 也可以读取多块内存然后拼接组合成最终的数据，但是这样性能并不好。这一点在官方源代码里的 bmap 结构体注释中有说明。

初始化

Go 语言初始化 map 的方式有两种，字面量和运行时。

字面量 “:=”

m := map[int]string {
    1: "go",
    2: "lang",
}

几乎所有语言都会提供字面量的方式进行初始化，Go 语言里的字面量初始化是使用了 “:=” 符号，这样来代表创建一个局部变量。Go 语言里的 map 也可以通过这种方式初始化，但是需要注意的是，还有一种初始化方式 var m map[Type]Type ，如果仅仅这样声明后就直接使用 m[key] = value 来写入是会 panic 的，因为没有分配实际内存。

通过这种方式初始化的 map 会调用 maplit 函数来执行具体的创建逻辑：

func maplit(n *Node, m *Node, init *Nodes) {
	a := nod(OMAKE, nil, nil)
	a.Esc = n.Esc
	a.List.Set2(typenod(n.Type), nodintconst(int64(n.List.Len())))
	litas(m, a, init)

	entries := n.List.Slice()

    // ...

	if len(entries) > 25 {
		// 如果数量非常多（指大于25个），就放进数组中循环处理。

		// 构建 [count]Tindex 和 [count]Tvalue
		tk := types.NewArray(n.Type.Key(), int64(len(entries)))
		te := types.NewArray(n.Type.Elem(), int64(len(entries)))
        
        // 后续循环插入，类似
        // for i = 0; i < len(vstatk); i++ {
		//	 map[vstatk[i]] = vstate[i]
		// }
        
        ...
    }

不管是哪种情况，最终都会通过 make 来创建哈希表数据结构并且通过 map[key] = value 的形式插入数据。

运行时 “make”

使用 make 创建 map 时有两种情况，一种是不给出大小，或者大小小于 8 的时候，会调用 makemap_small 来快速初始化一个 map：

func makemap_small() *hmap {
	h := new(hmap)
	h.hash0 = fastrand()
	return h
}

显而易见，这种的方式的 map 是声明在堆上的。除了这种方式之外，map 会通过 makemap64 来将 map 的大小设置为 int32 后再调用 makemap 函数进行创建的主要逻辑：

func makemap(t *maptype, hint int, h *hmap) *hmap {
	mem, overflow := math.MulUintptr(uintptr(hint), t.bucket.size)
	if overflow || mem > maxAlloc {
		hint = 0
	}

	if h == nil {
		h = new(hmap)
	}
	h.hash0 = fastrand()

	B := uint8(0)
	for overLoadFactor(hint, B) {
		B++
	}
	h.B = B

	if h.B != 0 {
		var nextOverflow *bmap
		h.buckets, nextOverflow = makeBucketArray(t, h.B, nil)
		if nextOverflow != nil {
			h.extra = new(mapextra)
			h.extra.nextOverflow = nextOverflow
		}
	}

	return h
}

makemap 函数做了这几件事：

用桶的个数*8，判断内存是否足够分配，会不会溢出，如果会的话就置 0。
声明一个 map 结构体变量，初始化一个随机数用于哈希函数的计算。
用 make 内置函数的第二个参数 hint 判断出需要多少个桶，转换为对数存到 B 中。
如果 B 是 0 的话，就不分配内存，后续用的时候懒加载分配，所以从这里我们也能明白为什么平时说提前给出 map 的大小后续使用速度更快了。如果不是 0，就调用 makeBucketArray 分配底层的桶内存和溢出桶内存。

这里会有一个判断 nextOverflow != nil ，这里就涉及在什么情况下初始化时要提前分配溢出桶，Go 语言是这样解决的：如果 B 大于 4，那么就认为后续使用溢出桶的概率比较大，就会预先分配 2^(B-4) 个溢出桶。然后分配专门用来描述溢出桶的结构 hmap.extra，其中指向下一个溢出桶地址的 nextOverflow 字段就指向分配好的溢出桶首地址。

正常桶和溢出桶的地址是连续的，只是被不同的字段引用而已，如果溢出桶不够用，会调用 runtime.newobject 分配新的溢出桶。直到达到元素数量过多需要全量扩容或者重新哈希等量扩容，这个问题下文会详说。

读写操作

Go 内置数据类型 map 是并发不安全的，也就是说多个 goroutine 同时对 map 执行写入操作会导致程序发生 panic 中断。官方解释说这是因为大多数情况下 map 并不需要并发安全，如果为所有 map 都加上并发操作的特性会使得大多数场景性能下降，为此 Go 在 1.9 版本引入了一种并发安全的 map 类型 sync/map ，留给读者自行探索。

访问

map 的访问有两种形式：

value := m["I'm a Key"]

value, ok := m["I'm a Key"]

第二种方式的第二个返回值是个布尔类型，代表该键在 map 中是否存在，类似于数据库或者其他概念中的 NULL 值，目的是为了不和所有该类型值冲突。两种方式的底层调用分别对应着 runtime/mapaccess1 和 runtime/mapaccess2 ，Go 语言会在 运行时决定 使用哪种方式。

func mapaccess1(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
    // ...
	hash := t.hasher(key, uintptr(h.hash0))
	m := bucketMask(h.B)
	b := (*bmap)(add(h.buckets, (hash&m)*uintptr(t.bucketsize)))
    // ...
	top := tophash(hash)
bucketloop:
	for ; b != nil; b = b.overflow(t) {
		for i := uintptr(0); i < bucketCnt; i++ {
			if b.tophash[i] != top {
				if b.tophash[i] == emptyRest {
					break bucketloop
				}
				continue
			}
			k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
			if t.indirectkey() {
				k = *((*unsafe.Pointer)(k))
			}
			if t.key.equal(key, k) {
				e := add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.elemsize))
				if t.indirectelem() {
					e = *((*unsafe.Pointer)(e))
				}
				return e
			}
		}
	}
	return unsafe.Pointer(&zeroVal[0])
}

mapaccess1 的返回值是一个指向目标值的指针，如果不存在的话会返回该类型的零值而不会返回 nil。

依次做了这些事：

通过 map 最开始初始化的哈希种子，用哈希函数计算出该键的哈希值 hash，这里的哈希函数使用了依赖注入的方式，并不固定。
计算桶的位掩码 m，也就是 B-1，用于后续做与运算确定该键位于哪个桶中。
与运算找到桶，桶的首地址+桶序号*桶大小动态计算出目标桶地址 b，取高八位哈希值 tophash，这里是通过位运算的方式取高位的，因为除法代价太高。
最后从桶的第一个 cell 开始，到最后一个溢出桶的最后一个 cell 为止遍历，先比较 tophash，如果一致了就用 tophash 值的下标和 map key 的大小计算出该 key 的偏移，再比较一次，这样可以加速查找，

第二种形式的底层调用是 mapaccess2 ，过程和第一种类似，只是在最后的两个 return 处多返回了一个布尔值：

				// ...
				return e, true
			}
		}
	}
	return unsafe.Pointer(&zeroVal[0]), false

还有一个函数 mapaccessK ，返回的是 map 的 key 和 value，用于 map 的 range 函数遍历，过程类似，不赘述了。

写入

map 的写入操作对应底层 runtime/map.go.mapassign 函数。这个函数的签名如下：

func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer

签名中并没有看到写入 key 所对应的 value 值表达式，唯一相关的返回值是一个指向任意类型的指针类型，可能有人就迷惑了，map 写入是依靠这个函数，我都没传 value 怎么写入呢？

答案是写入操作并没有写在标准库源码中，而是在汇编代码中。

...
0x008e 00142 (notify.go:5)      CALL    runtime.mapassign_fast64(SB)
0x0093 00147 (notify.go:5)      MOVQ    24(SP), AX
0x0098 00152 (notify.go:5)      MOVQ    $666, (AX)
...

学习 Go 底层原理时，时常要借助汇编代码一起分析，Go 官方也为我们提供了完整的工具包，其中 go tool compile -S 就十分有用，上面这些信息就是通过这个工具得到的。

mapassign_fast64 是针对不同类型的 key 做出的编译时优化，为了增加效率。

下面看一下这个函数的源码：

func mapassign(t *maptype, h *hmap, key unsafe.Pointer) unsafe.Pointer {
    // 向空map中写入会panic，比如仅仅通过
    // var mp map[int]int
    // mp[1] = 2 // panic!
	if h == nil {
		panic(plainError("assignment to entry in nil map"))
	}
	...
    // 写map时会把flags标志位写位置1，写入时如果检测到已经置1，
    // 说明并发写入，语言不支持，会panic
	if h.flags&hashWriting != 0 {
		throw("concurrent map writes")
	}
	hash := t.hasher(key, uintptr(h.hash0))

    // 这个要在t.hasher之后，因为hasher调用可能panic，导致写入失败，没必要把写入位置1
	h.flags ^= hashWriting

    // 如果还没有桶就new一个
	if h.buckets == nil {
		h.buckets = newobject(t.bucket) // newarray(t.bucket, 1)
	}

again:
	bucket := hash & bucketMask(h.B)	// 与低B位确定在哪个桶
	if h.growing() {	// 这个函数只有一行代码，h.oldbuckets != nil，判断是否迁移完毕
		growWork(t, h, bucket)
	}
	b := (*bmap)(add(h.buckets, bucket*uintptr(t.bucketsize)))// 用首地址+桶编号*单个桶大小定位到目标桶的地址
	top := tophash(hash) // 计算tophash哈希值，用于找到key value

    // 完成了上面的各种判断，才会进行下面双重循环的判断，按照所有桶，每个桶里的8个位，按顺序遍历
	var inserti *uint8
	var insertk unsafe.Pointer
	var elem unsafe.Pointer
bucketloop:
	for {
		for i := uintptr(0); i < bucketCnt; i++ {
			if b.tophash[i] != top {
				if isEmpty(b.tophash[i]) && inserti == nil {
					inserti = &b.tophash[i]
					insertk = add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
					elem = add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.elemsize))
				}
				if b.tophash[i] == emptyRest {
					break bucketloop
				}
				continue
			}
			k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
			if t.indirectkey() {
				k = *((*unsafe.Pointer)(k))
			}
			if !t.key.equal(key, k) {
				continue
			}
			// already have a mapping for key. Update it.
			if t.needkeyupdate() {
				typedmemmove(t.key, k, key)
			}
			elem = add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.elemsize))
			goto done
		}
		ovf := b.overflow(t)
		if ovf == nil {
			break
		}
		b = ovf
	}

	// Did not find mapping for key. Allocate new cell & add entry.

	// If we hit the max load factor or we have too many overflow buckets,
	// and we're not already in the middle of growing, start growing.
	if !h.growing() && (overLoadFactor(h.count+1, h.B) || tooManyOverflowBuckets(h.noverflow, h.B)) {
		hashGrow(t, h)
		goto again // Growing the table invalidates everything, so try again
	}

	if inserti == nil {
		// The current bucket and all the overflow buckets connected to it are full, allocate a new one.
		newb := h.newoverflow(t, b)
		inserti = &newb.tophash[0]
		insertk = add(unsafe.Pointer(newb), dataOffset)
		elem = add(insertk, bucketCnt*uintptr(t.keysize))
	}

	// store new key/elem at insert position
	if t.indirectkey() {
		kmem := newobject(t.key)
		*(*unsafe.Pointer)(insertk) = kmem
		insertk = kmem
	}
	if t.indirectelem() {
		vmem := newobject(t.elem)
		*(*unsafe.Pointer)(elem) = vmem
	}
	typedmemmove(t.key, insertk, key)
	*inserti = top
	h.count++

done:
	if h.flags&hashWriting == 0 {
		throw("concurrent map writes")
	}
	h.flags &^= hashWriting
	if t.indirectelem() {
		elem = *((*unsafe.Pointer)(elem))
	}
    
    // 返回elem地址，由汇编代码负责执行真正的写入操作
	return elem
}

删除

删除对应的底层函数是 runtime/map.mapdelete ，处理的思路非常相似，也是先判断各种情况，最后进行双重循环定位目标 cell，不再赘述了。

扩容

扩容过程较为复杂，总的来说，扩容分为增量扩容与等量扩容，前者有两种情况触发，一是在桶不够用时，即容量到达扩容因子时，二是在，后者是在桶空间较为稀疏时触发，作用不同。

需要注意的一点是，扩容并不是一次性完成的，而是渐进式的，在每次进行写入操作时搬运一部分元素，主要目的也是为了防止瞬时的性能抖动对整个应用造成影响。

等量扩容

等量扩容的目的是使得桶的数据密度不至于过小，想象一种极端场景，一个哈希表有1个位置，拉链出了100个bucket，但只有一个元素，它在最后一个桶（正常桶+溢出桶）的最后一个位置上，我们每次访问这个元素，都需要从头到尾扫描这n个桶，直到找到这个元素，显而易见，这样效率非常低，所以go语言运行时会动态修改这个大小，进行数据的紧缩，使得数据密度增大增大，既增加了效率，也减少了所需空间。

等量扩容的代码在 xxxxx，

主要做了这些事：

增量扩容

增量扩容的出现场景就是桶不够用，即容量到达了负载因子的限制大小，需要进行扩大，具体与hmap。b的大小有关：

当b《=15时，如果桶大小一旦超过这个值扩容
当b》15，如果桶大小大于2…………15次方就扩容

扩容时由于b的大小+1，所以掩码的低位位数会+1，最高位的0和1会把所有元素分到两个部分，在go中这两部分被命名为 evaluatex，evaluatey，

具体代码放在 xxxx，

总结

Go 语言的 map 使用了数组+链表实现的哈希表，引入了溢出桶的概念以及触发扩容的条件机制来减少桶的扩容，实现了平均 O(1) 的时间复杂度内访问元素，基本不会出现最坏的情况。

访问元素的大致流程时：经过哈希计算后，用低 B 位确定桶位置，高 8 位比对 tophash 找到偏移，再通过偏移找到 key/value，或者执行插入或者新增溢出桶等等逻辑。

不管你使用字面量的方式还是 make 的方式声明 map，都是对应底层的 hmap 结构，获得了一个指向 hmap 的指针，并且 Go 语言针对不给出初始大小的 map 还进行了快速初始化的优化，针对 map 的大小过大（hmap.B 大于4），提前建立溢出桶的优化。

Go 提供了两种方式访问 map 中的元素，可以获得两个返回值，第二个返回值可以忽略，这用于空键值对的判断，类似于数据库中的 NULL，不和任何值冲突。并且 map 的遍历访问是随机的，这是因为每次遍历时会通过 fastrand 生成一个随机数，随机选择一个桶，再随机选择桶中的一个元素，先遍历完该桶，再顺次遍历后续的桶。map 是可以并发访问（指读）的，因为这并不会有任何冲突发生。

Go 系列 · Wasabi

Go 语言代码安全指南

通用类

1. 代码实现类

1.1 内存管理

1.1.1【必须】切片长度校验

1.1.2【必须】nil指针判断

1.1.3【必须】整数安全

1.1.4【必须】make分配长度验证

1.1.5【必须】禁止SetFinalizer和指针循环引用同时使用

1.1.6【必须】禁止重复释放channel

1.1.7【必须】确保每个协程都能退出

1.1.8【推荐】不使用unsafe包

1.1.9【推荐】不使用slice作为函数入参

1.2 文件操作

1.2.1【必须】 路径穿越检查

1.2.2【必须】 文件访问权限

1.3 系统接口

1.4 通信安全

1.4.1【必须】网络通信采用TLS方式

1.4.2【推荐】TLS启用证书验证

1.5 敏感数据保护

1.5.1【必须】敏感信息访问

1.5.2【必须】敏感数据输出

1.5.3【必须】敏感数据存储

1.5.4【必须】异常处理和日志记录

1.6 加密解密

1.6.1【必须】不得硬编码密码/密钥

1.6.2【必须】密钥存储安全

1.6.3【推荐】不使用弱密码算法

1.7 正则表达式

1.7.1【推荐】使用regexp进行正则表达式匹配

后台类

1 代码实现类

1.1 输入校验

1.1.1【必须】按类型进行数据校验

1.2 SQL操作

1.2.1【必须】SQL语句默认使用预编译并绑定变量

1.3 网络请求

1.3.1【必须】资源请求过滤验证

1.4 服务器端渲染

1.4.1【必须】模板渲染过滤验证

1.5 Web跨域

1.5.1【必须】跨域资源共享CORS限制请求来源

1.6 响应输出

1.6.1 【必须】设置正确的HTTP响应包类型

1.6.2 【必须】添加安全响应头

1.6.3【必须】外部输入拼接到HTTP响应头中需进行过滤

1.6.4【必须】外部输入拼接到response页面前进行编码处理

1.7 会话管理

1.7.1【必须】安全维护session信息

1.7.2【必须】CSRF防护

1.8 访问控制

1.8.1【必须】默认鉴权

1.9 并发保护

1.9.1【必须】禁止在闭包中直接调用循环变量

1.9.2【必须】禁止并发写map

1.9.3【必须】确保并发安全

Go 使用的 plan9 汇编语言初探

伪寄存器

与x86汇编的差异

操作数顺序不同

操作数大小表示法不同

寄存器

伪寄存器

函数调用

栈帧

验证

分析一个简单的程序

前置知识

变量与常量

函数

手写来练习一下吧

总结

Go unsafe.Pointer、uintptr、Pointer 之间的区别与联系

unsafe包

一类型Pointer

类型介绍

使用注意

uintptr变量无法保持对变量的引用

1.2.1【必须】路径穿越检查

1.2.2【必须】文件访问权限