diff --git a/discuss/2018-05-21-using-goroutines-on-loop-iterator-variables.md b/discuss/2018-05-21-using-goroutines-on-loop-iterator-variables.md
index e64a7034..4947ead8 100644
--- a/discuss/2018-05-21-using-goroutines-on-loop-iterator-variables.md
+++ b/discuss/2018-05-21-using-goroutines-on-loop-iterator-variables.md
@@ -27,9 +27,9 @@ time.Sleep(time.Second)
 延伸出来的知识点：惰性求值和闭包。
 
 解答：
-根据问题的描述推断出是闭包的特性，通过Google检索关键字*glang faq loop closure*可找到官方的[faq](https://golang.org/doc/faq#closures_and_goroutines)，里面有详细的解释，并提醒了用户可以通过__go vet__命令来检查程序中类似的问题。
+根据问题的描述推断出是闭包的特性，通过Google检索关键字 **glang faq loop closure** 可找到官方的[faq](https://golang.org/doc/faq#closures_and_goroutines)，里面有详细的解释，并提醒了用户可以通过 *go vet*命令来检查程序中类似的问题。
 
-最后官方的faq还给出了针对这个问题的两种解决方法。其中第一种方法很好理解，就是把变量v的值通过参数的形式传递给goroutine，因为go中func的参数都是值传递，所以这样就在goroutine启动是获得了当前v变量的值。
+最后官方的faq还给出了针对这个问题的两种解决方法。其中第一种方法很好理解，就是把变量v的值通过参数的形式传递给goroutine，因为go中func的参数传递都是值传递，所以就在goroutine启动时获得了当前v变量的值。
 ```go
 for _, v := range values {
     go func(u string) {
@@ -48,7 +48,7 @@ for _, v := range values {
     }()
 }
 ```
-如果没有明白其中的原理，只要自己把赋值前后变量v的内存地址打印出来就明白了，在赋值后新的v变量实际上是在内存中开辟了一个新的空间并保存了当前v变量的值，两个v变量并不是指向相同的内存地址。
+如果没有明白其中的原理，只要自己把赋值前后变量v的内存地址打印出来就明白了，在赋值后新的变量v实际上是在内存中开辟了一个新的空间并保存了当前变量v的值，两个变量并不是指向相同的内存地址。
 ```go
 for _, v := range values {
     fmt.Printf("Before assignment:%p\n", &v)