本文目录一览：
- 1、GoLang -- Gin框架
- 2、彻底理解Golang Map
- 3、golang如何实现urldecode
- 4、bpftrace动态追踪golang应用-函数内联问题
- 5、如何在golang 中调用c的静态库或者动态库
- 6、golang项目中使用条件编译
GoLang -- Gin框架
• 何为框架：
框架一直是敏捷开发中的利器，能让开发者很快的上手并做出应用，甚至有的时候，脱离了框架，一些开发者都不会写程序了。成长总不会一蹴而就，从写出程序获取成就感，再到精通框架，快速构造应用，当这些方面都得心应手的时候，可以尝试改造一些框架，或是自己创造一个。
Gin是一个golang的微框架，封装比较优雅，API友好，源码注释比较明确，已经发布了1.0版本。具有快速灵活，容错方便等特点。其实对于golang而言，web框架的依赖要远比Python，Java之类的要小。自身的net/http足够简单，性能也非常不错。框架更像是一些常用函数或者工具的集合。借助框架开发，不仅可以省去很多常用的封装带来的时间，也有助于团队的编码风格和形成规范。
（1）首先需要安装，安装比较简单，使用go get即可
go get github.com/gin-gonic/gin
如果安装失败，直接去Github clone下来，放置到对应的目录即可。
（2）代码中使用：
下面是一个使用Gin的简单例子：
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
router := gin.Default()
router.GET("/ping", func(c *gin.Context) {
c.JSON(200, gin.H{
"message": "pong",
})
})
router.Run(":8080") // listen and serve on 0.0.0.0:8080
}
简单几行代码，就能实现一个web服务。使用gin的Default方法创建一个路由handler。然后通过HTTP方法绑定路由规则和路由函数。不同于net/http库的路由函数，gin进行了封装，把request和response都封装到gin.Context的上下文环境。最后是启动路由的Run方法监听端口。麻雀虽小，五脏俱全。当然，除了GET方法，gin也支持POST,PUT,DELETE,OPTION等常用的restful方法。
Gin可以很方便的支持各种HTTP请求方法以及返回各种类型的数据，详情可以前往查看。
2.1 匹配参数
我们可以使用Gin框架快速的匹配参数，如下代码所示：
冒号:加上一个参数名组成路由参数。可以使用c.Param的方法读取其值。当然这个值是字串string。诸如/user/rsj217，和/user/hello都可以匹配，而/user/和/user/rsj217/不会被匹配。
浏览器输入以下测试：
返回结果为：
其中c.String是gin.Context下提供的方法，用来返回字符串。
其中c.Json是gin.Context下提供的方法，用来返回Json。
下面我们使用以下gin提供的Group函数，方便的为不同的API进行分类。
我们创建了一个gin的默认路由，并为其分配了一个组 v1，监听hello请求并将其路由到视图函数HelloPage，最后绑定到 0.0.0.0:8000
C.JSON是Gin实现的返回json数据的内置方法，包含了2个参数，状态码和返回的内容。http.StatusOK代表返回状态码为200，正文为{"message": “welcome"}。
注：Gin还包含更多的返回方法如c.String, c.HTML, c.XML等，请自行了解。可以方便的返回HTML数据
我们在之前的组v1路由下新定义一个路由：
下面我们访问
可以看到，通过c.Param(“key”)方法，Gin成功捕获了url请求路径中的参数。同理，gin也可以捕获常规参数，如下代码所示：
在浏览器输入以下代码：
通过c.Query(“key”)可以成功接收到url参数，c.DefaultQuery在参数不存在的情况下，会由其默认值代替。
我们还可以为Gin定义一些默认路由：
这时候，我们访问一个不存在的页面：
返回如下所示：
下面我们测试在Gin里面使用Post
在测试端输入：
附带发送的数据，测试即可。记住需要使用POST方法.
继续修改，将PostHandler的函数修改如下
测试工具输入：
发送的内容输入：
返回结果如下：
备注：此处需要指定Content-Type为application/x-www-form-urlencoded，否则识别不出来。
一定要选择对应的PUT或者DELETE方法。
Gin框架快速的创建路由
能够方便的创建分组
支持url正则表达式
支持参数查找（c.Param c.Query c.PostForm）
请求方法精准匹配
支持404处理
快速的返回给客户端数据，常用的c.String c.JSON c.Data
彻底理解Golang Map
本文目录如下，阅读本文后，将一网打尽下面Golang Map相关面试题
Go中的map是一个指针，占用8个字节，指向hmap结构体; 源码 src/runtime/map.go 中可以看到map的底层结构
每个map的底层结构是hmap，hmap包含若干个结构为bmap的bucket数组。每个bucket底层都采用链表结构。接下来，我们来详细看下map的结构
bmap 就是我们常说的“桶”，一个桶里面会最多装 8 个 key，这些 key 之所以会落入同一个桶，是因为它们经过哈希计算后，哈希结果是“一类”的，关于key的定位我们在map的查询和插入中详细说明。在桶内，又会根据 key 计算出来的 hash 值的高 8 位来决定 key 到底落入桶内的哪个位置（一个桶内最多有8个位置)。
bucket内存数据结构可视化如下：
注意到 key 和 value 是各自放在一起的，并不是 key/value/key/value/... 这样的形式。源码里说明这样的好处是在某些情况下可以省略掉 padding字段，节省内存空间。
当 map 的 key 和 value 都不是指针，并且 size 都小于 128 字节的情况下，会把 bmap 标记为不含指针，这样可以避免 gc 时扫描整个 hmap。但是，我们看 bmap 其实有一个 overflow 的字段，是指针类型的，破坏了 bmap 不含指针的设想，这时会把 overflow 移动到 extra 字段来。
map是个指针，底层指向hmap，所以是个引用类型
golang 有三个常用的高级类型 slice 、map、channel, 它们都是 引用类型 ，当引用类型作为函数参数时，可能会修改原内容数据。
golang 中没有引用传递，只有值和指针传递。所以 map 作为函数实参传递时本质上也是值传递，只不过因为 map 底层数据结构是通过指针指向实际的元素存储空间，在被调函数中修改 map，对调用者同样可见，所以 map 作为函数实参传递时表现出了引用传递的效果。
因此，传递 map 时，如果想修改map的内容而不是map本身，函数形参无需使用指针
map 底层数据结构是通过指针指向实际的元素 存储空间 ，这种情况下，对其中一个map的更改，会影响到其他map
map 在没有被修改的情况下，使用 range 多次遍历 map 时输出的 key 和 value 的顺序可能不同。这是 Go 语言的设计者们有意为之，在每次 range 时的顺序被随机化，旨在提示开发者们，Go 底层实现并不保证 map 遍历顺序稳定，请大家不要依赖 range 遍历结果顺序。
map 本身是无序的，且遍历时顺序还会被随机化，如果想顺序遍历 map，需要对 map key 先排序，再按照 key 的顺序遍历 map。
map默认是并发不安全的，原因如下：
Go 官方在经过了长时间的讨论后，认为 Go map 更应适配典型使用场景（不需要从多个 goroutine 中进行安全访问），而不是为了小部分情况（并发访问），导致大部分程序付出加锁代价（性能），决定了不支持。
场景: 2个协程同时读和写，以下程序会出现致命错误：fatal error: concurrent map writes
如果想实现map线程安全，有两种方式：
方式一：使用读写锁 map + sync.RWMutex
方式二：使用golang提供的 sync.Map
sync.map是用读写分离实现的，其思想是空间换时间。和map+RWLock的实现方式相比，它做了一些优化：可以无锁访问read map，而且会优先操作read map，倘若只操作read map就可以满足要求(增删改查遍历)，那就不用去操作write map(它的读写都要加锁)，所以在某些特定场景中它发生锁竞争的频率会远远小于map+RWLock的实现方式。
golang中map是一个kv对集合。底层使用hash table，用链表来解决冲突 ，出现冲突时，不是每一个key都申请一个结构通过链表串起来，而是以bmap为最小粒度挂载，一个bmap可以放8个kv。在哈希函数的选择上，会在程序启动时，检测 cpu 是否支持 aes，如果支持，则使用 aes hash，否则使用 memhash。
map有3钟初始化方式，一般通过make方式创建
map的创建通过生成汇编码可以知道，make创建map时调用的底层函数是 runtime.makemap 。如果你的map初始容量小于等于8会发现走的是 runtime.fastrand 是因为容量小于8时不需要生成多个桶，一个桶的容量就可以满足
makemap函数会通过 fastrand 创建一个随机的哈希种子，然后根据传入的 hint 计算出需要的最小需要的桶的数量，最后再使用 makeBucketArray 创建用于保存桶的数组，这个方法其实就是根据传入的 B 计算出的需要创建的桶数量在内存中分配一片连续的空间用于存储数据，在创建桶的过程中还会额外创建一些用于保存溢出数据的桶，数量是 2^(B-4) 个。初始化完成返回hmap指针。
找到一个 B，使得 map 的装载因子在正常范围内
Go 语言中读取 map 有两种语法：带 comma 和 不带 comma。当要查询的 key 不在 map 里，带 comma 的用法会返回一个 bool 型变量提示 key 是否在 map 中；而不带 comma 的语句则会返回一个 value 类型的零值。如果 value 是 int 型就会返回 0，如果 value 是 string 类型，就会返回空字符串。
map的查找通过生成汇编码可以知道，根据 key 的不同类型，编译器会将查找函数用更具体的函数替换，以优化效率：
函数首先会检查 map 的标志位 flags。如果 flags 的写标志位此时被置 1 了，说明有其他协程在执行“写”操作，进而导致程序 panic。这也说明了 map 对协程是不安全的。
key经过哈希函数计算后，得到的哈希值如下（主流64位机下共 64 个 bit 位）：
m: 桶的个数
从buckets 通过 hash m 得到对应的bucket，如果bucket正在扩容，并且没有扩容完成，则从oldbuckets得到对应的bucket
计算hash所在桶编号：
用上一步哈希值最后的 5 个 bit 位，也就是 01010 ，值为 10，也就是 10 号桶（范围是0~31号桶）
计算hash所在的槽位:
用上一步哈希值哈希值的高8个bit 位，也就是 10010111 ，转化为十进制，也就是151，在 10 号 bucket 中寻找** tophash 值（HOB hash）为 151* 的 槽位**，即为key所在位置，找到了 2 号槽位，这样整个查找过程就结束了。
如果在 bucket 中没找到，并且 overflow 不为空，还要继续去 overflow bucket 中寻找，直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket。
通过上面找到了对应的槽位，这里我们再详细分析下key/value值是如何获取的：
bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 个 key 的地址就要在此基础上跨过 i 个 key 的大小；而我们又知道，value 的地址是在所有 key 之后，因此第 i 个 value 的地址还需要加上所有 key 的偏移。
通过汇编语言可以看到，向 map 中插入或者修改 key，最终调用的是 mapassign 函数。
实际上插入或修改 key 的语法是一样的，只不过前者操作的 key 在 map 中不存在，而后者操作的 key 存在 map 中。
mapassign 有一个系列的函数，根据 key 类型的不同，编译器会将其优化为相应的“快速函数”。
我们只用研究最一般的赋值函数 mapassign 。
map的赋值会附带着map的扩容和迁移，map的扩容只是将底层数组扩大了一倍，并没有进行数据的转移，数据的转移是在扩容后逐步进行的，在迁移的过程中每进行一次赋值（access或者delete）会至少做一次迁移工作。
1.判断map是否为nil
每一次进行赋值/删除操作时，只要oldbuckets != nil 则认为正在扩容，会做一次迁移工作，下面会详细说下迁移过程
根据上面查找过程，查找key所在位置，如果找到则更新，没找到则找空位插入即可
经过前面迭代寻找动作，若没有找到可插入的位置，意味着需要扩容进行插入，下面会详细说下扩容过程
通过汇编语言可以看到，向 map 中删除 key，最终调用的是 mapdelete 函数
删除的逻辑相对比较简单，大多函数在赋值操作中已经用到过，核心还是找到 key 的具体位置。寻找过程都是类似的，在 bucket 中挨个 cell 寻找。找到对应位置后，对 key 或者 value 进行“清零”操作，将 count 值减 1，将对应位置的 tophash 值置成 Empty
再来说触发 map 扩容的时机：在向 map 插入新 key 的时候，会进行条件检测，符合下面这 2 个条件，就会触发扩容：
1、装载因子超过阈值
源码里定义的阈值是 6.5 (loadFactorNum/loadFactorDen)，是经过测试后取出的一个比较合理的因子
我们知道，每个 bucket 有 8 个空位，在没有溢出，且所有的桶都装满了的情况下，装载因子算出来的结果是 8。因此当装载因子超过 6.5 时，表明很多 bucket 都快要装满了，查找效率和插入效率都变低了。在这个时候进行扩容是有必要的。
对于条件 1，元素太多，而 bucket 数量太少，很简单：将 B 加 1，bucket 最大数量( 2^B )直接变成原来 bucket 数量的 2 倍。于是，就有新老 bucket 了。注意，这时候元素都在老 bucket 里，还没迁移到新的 bucket 来。新 bucket 只是最大数量变为原来最大数量的 2 倍( 2^B * 2 ) 。
2、overflow 的 bucket 数量过多
在装载因子比较小的情况下，这时候 map 的查找和插入效率也很低，而第 1 点识别不出来这种情况。表面现象就是计算装载因子的分子比较小，即 map 里元素总数少，但是 bucket 数量多（真实分配的 bucket 数量多，包括大量的 overflow bucket）
不难想像造成这种情况的原因：不停地插入、删除元素。先插入很多元素，导致创建了很多 bucket，但是装载因子达不到第 1 点的临界值，未触发扩容来缓解这种情况。之后，删除元素降低元素总数量，再插入很多元素，导致创建很多的 overflow bucket，但就是不会触发第 1 点的规定，你能拿我怎么办？overflow bucket 数量太多，导致 key 会很分散，查找插入效率低得吓人，因此出台第 2 点规定。这就像是一座空城，房子很多，但是住户很少，都分散了，找起人来很困难
对于条件 2，其实元素没那么多，但是 overflow bucket 数特别多，说明很多 bucket 都没装满。解决办法就是开辟一个新 bucket 空间，将老 bucket 中的元素移动到新 bucket，使得同一个 bucket 中的 key 排列地更紧密。这样，原来，在 overflow bucket 中的 key 可以移动到 bucket 中来。结果是节省空间，提高 bucket 利用率，map 的查找和插入效率自然就会提升。
由于 map 扩容需要将原有的 key/value 重新搬迁到新的内存地址，如果有大量的 key/value 需要搬迁，会非常影响性能。因此 Go map 的扩容采取了一种称为“渐进式”的方式，原有的 key 并不会一次性搬迁完毕，每次最多只会搬迁 2 个 bucket。
上面说的 hashGrow() 函数实际上并没有真正地“搬迁”，它只是分配好了新的 buckets，并将老的 buckets 挂到了 oldbuckets 字段上。真正搬迁 buckets 的动作在 growWork() 函数中，而调用 growWork() 函数的动作是在 mapassign 和 mapdelete 函数中。也就是插入或修改、删除 key 的时候，都会尝试进行搬迁 buckets 的工作。先检查 oldbuckets 是否搬迁完毕，具体来说就是检查 oldbuckets 是否为 nil。
如果未迁移完毕，赋值/删除的时候，扩容完毕后（预分配内存），不会马上就进行迁移。而是采取 增量扩容 的方式，当有访问到具体 bukcet 时，才会逐渐的进行迁移（将 oldbucket 迁移到 bucket）
nevacuate 标识的是当前的进度，如果都搬迁完，应该和2^B的长度是一样的
在evacuate 方法实现是把这个位置对应的bucket，以及其冲突链上的数据都转移到新的buckets上。
转移的判断直接通过tophash 就可以，判断tophash中第一个hash值即可
遍历的过程，就是按顺序遍历 bucket，同时按顺序遍历 bucket 中的 key。
map遍历是无序的，如果想实现有序遍历，可以先对key进行排序
为什么遍历 map 是无序的？
如果发生过迁移，key 的位置发生了重大的变化，有些 key 飞上高枝，有些 key 则原地不动。这样，遍历 map 的结果就不可能按原来的顺序了。
如果就一个写死的 map，不会向 map 进行插入删除的操作，按理说每次遍历这样的 map 都会返回一个固定顺序的 key/value 序列吧。但是 Go 杜绝了这种做法，因为这样会给新手程序员带来误解，以为这是一定会发生的事情，在某些情况下，可能会酿成大错。
Go 做得更绝，当我们在遍历 map 时，并不是固定地从 0 号 bucket 开始遍历，每次都是从一个**随机值序号的 bucket 开始遍历，并且是从这个 bucket 的一个 随机序号的 cell **开始遍历。这样，即使你是一个写死的 map，仅仅只是遍历它，也不太可能会返回一个固定序列的 key/value 对了。
golang如何实现urldecode
首先你的理解是错的，不管用户态的API(syscall)是否是同步还是异步，在kernel层面都是异步的。
其实实现原理很简单，就是利用C(嵌入汇编)语言可以直接修改寄存器(setcontext/setjmp/longjmp均是类似原理，修改程序指针eip实现跳转，栈指针实现上线文切换)来实现从func_a调进去，从func_b返回出来这种行为。对于golang来说，func_a/func_b属于不同的goroutine，从而就实现了goroutine的调度切换。
另外对于所有可能阻塞的syscall，golang对其进行了封装，底层实际是epoll方式做的，注册回调后切换到另一个runnable的goroutine。
bpftrace动态追踪golang应用-函数内联问题
在上一篇文章的golang代码中，函数add的上一行，增加了一条注释语句： //go:noinline 。在bpftrace追踪时，是否可以去掉？有什么作用？
为了说明该问题，设计一个例子。
golang代码中，有两个求和函数。其中，add1加上 //go:noinline ，另一个add2不加。代码如下：
bpftrace程序分别对函数add1和add2的输入参数、返回值进行追踪，代码如下：
执行程序后，可以看到bpftrace程序能够正常追踪到函数add1，但是无法追踪到函数add2。
通过上文中的示例代码，可以看到，没有加 //go:noinline 的函数无法被bpftrace程序追踪到。通过查阅golang相关文档，可以知道， //go:noinline 表示该函数在编译时，不会被内联。
使用 objump -S 生成golang程序的汇编代码如下：
通过汇编代码，我们可以看到，主函数中，地址 0x498e52 处 callq 498e00 调用了add1函数，地址 0x498ebb 处 movq $0x4,(%rsp) 直接计算求值。
因此，golang编译器在编译代码时，会对代码进行分析，并按照内联规则，将某些函数生成内联代码。一旦函数被内联，bpftrace将无法追踪到对应函数。也就是，上文中函数 add2 无法被追踪到。
针对golang程序中编译器内联的问题，可以通过禁止内联的方式来解决。禁止内联的方式有：
在实践中，可以通过 go build -gcflags="-m -m" 来查看，哪些函数会在编译时执行内联，如：
从输出中，可以看到：
关于golang编译器进行内联的场景，可以参考golang源码：。
由于golang编译器内联优化，bpftrace可能无法正常追踪golang程序。在编写bpftrace脚本时，可以先使用 nm 命令查看一下可执行程序，是否存在需要追踪的函数的符号信息。如果没有则bpftrace将不能对其进行追踪。
前面的示例中，都是对 int 类型的参数进行追踪，那对于 string 类型的参数，是否也可以用同样的方式进行追踪？将在下一篇中进行讨论。
如何在golang 中调用c的静态库或者动态库
Cgo 使得Go程序能够调用C代码. cgo读入一个用特别的格式写的Go语言源文件, 输出Go和C程序, 使得C程序能打包到Go语言的程序包中.
举例说明一下. 下面是一个Go语言包, 包含了两个函数 -- Random 和 Seed -- 是C语言库中random和srandom函数的马甲.
package rand
/*
#include stdlib.h
*/ import "C" func Random() int { return int(C.random()) } func Seed(i int) { C.srandom(C.uint(i)) }
我们来看一下这里都有什么内容. 开始是一个包的导入语句.
rand包导入了"C"包, 但你会发现在Go的标准库里没有这个包. 那是因为C是一个"伪包", 一个为cgo引入的特殊的包名, 它是C命名空间的一个引用.
rand 包包含4个到C包的引用: 调用 C.random和C.srandom, 类型转换 C.uint(i)还有引用语句.
Random函数调用libc中的random函数, 然后回返结果. 在C中, random返回一个C类型的长整形值, cgo把它轮换为C.long. 这个值必需转换成Go的类型, 才能在Go程序中使用. 使用一个常见的Go类型转换:
func Random() int { return int(C.random()) }
这是一个等价的函数, 使用了一个临时变量来进行类型转换:
func Random() int { var r C.long = C.random() return int(r) }
Seed函数则相反. 它接受一个Go语言的int类型, 转换成C语言的unsigned int类型, 然后传递给C的srandom函数.
func Seed(i int) { C.srandom(C.uint(i)) }
需要注意的是, cgo中的unsigned int类型写为C.uint; cgo的文档中有完整的类型列表.
这个例子中还有一个细节我们没有说到, 那就是导入语句上面的注释.
/*
#include stdlib.h
*/ import "C"
Cgo可以识别这个注释, 并在编译C语言程序的时候将它当作一个头文件来处理. 在这个例子中, 它只是一个include语句, 然而其实它可以是使用有效的C语言代码. 这个注释必需紧靠在import "C"这个语句的上面, 不能有空行, 就像是文档注释一样.
Strings and things
与Go语言不同, C语言中没有显式的字符串类型. 字符串在C语言中是一个以0结尾的字符数组.
Go和C语言中的字符串转换是通过C.CString, C.GoString,和C.GoStringN这些函数进行的. 这些转换将得到字符串类型的一个副本.
下一个例子是实现一个Print函数, 它使用C标准库中的fputs函数把一个字符串写到标准输出上:
package print // #include stdio.h // #include stdlib.h import "C" import "unsafe" func Print(s string) { cs := C.CString(s) C.fputs(cs, (*C.FILE)(C.stdout)) C.free(unsafe.Pointer(cs)) }
在C程序中进行的内存分配是不能被Go语言的内存管理器感知的. 当你使用C.CString创建一个C字符串时(或者其它类型的C语言内存分配), 你必需记得在使用完后用C.free来释放它.
调用C.CString将返回一个指向字符数组开始处的指错, 所以在函数退出前我们把它转换成一个unsafe.Pointer(Go中与C的void 等价的东西), 使用C.free来释放分配的内存. 一个惯用法是在分配内存后紧跟一个defer(特别是当这段代码比较复杂的时候), 这样我们就有了下面这个Print函数:
func Print(s string) { cs := C.CString(s) defer C.free(unsafe.Pointer(cs)) C.fputs(cs, (*C.FILE)(C.stdout)) }
构建 cgo 包
如果你使用goinstall, 构建cgo包就比较容易了, 只要调用像平常一样使用goinstall命令, 它就能自动识别这个特殊的import "C", 然后自动使用cgo来编译这些文件.
如果你想使用Go的Makefiles来构建, 那在CGOFILES变量中列出那些要用cgo处理的文件, 就像GOFILES变量包含一般的Go源文件一样.
rand包的Makefile可以写成下面这样:
include $(GOROOT)/src/Make.inc
TARG=goblog/rand
CGOFILES=\ rand.go\ include $(GOROOT)/src/Make.pkg
然后输入gomake开始构建.
更多 cgo 的资源
cgo的文档中包含了关于C伪包的更多详细的说明, 以及构建过程. Go代码树中的cgo的例子给出了更多更高级的用法.
一个简单而又符合Go惯用法的基于cgo的包是Russ Cox写的gosqlite. 而Go语言的网站上也列出了更多的的cgo包.
最后, 如果你对于cgo的内部是怎么运作这个事情感到好奇的话, 去看看运行时包的cgocall.c文件的注释吧.
golang项目中使用条件编译
golang中没有类似C语言中条件编译的写法，比如在C代码中可以使用如下语法做一些条件编译，结合宏定义来使用可以实现诸如按需编译release和debug版本代码的需求
build tags 是通过代码注释的形式实现的，要写在文件的最顶端；
go build指令在编译项目的时候会检查每一个文件的build tags，用来决定是编译还是跳过该文件
build tags遵循以下规则
示例：
约束此文件只能在支持kqueue的BSD系统上编译
一个文件可能包含多行条件编译注释，比如：
约束该文件在linux/386 或 darwin/386平台编译
需要注意的点
正确的写法如下：
编译方法:
具有_$GOOS.go后缀的go文件在编译的时候会根据当前平台来判断是否将该文件导入并编译；同样适用于处理器架构判断 _$GOARCH.go。
两者可以结合起来使用，形式为： _$GOOS_$GOARCH.go
示例：
文件名必须提供，如果只由后缀的文件名会被编译器忽略，比如：
这两个文件会被编译器忽略，因为以下划线开头的文件都会被忽略
