diff --git a/course-book/contents/basic/result-error/panic.md b/course-book/contents/basic/result-error/panic.md
index 4b6acca6..0fa076b1 100644
--- a/course-book/contents/basic/result-error/panic.md
+++ b/course-book/contents/basic/result-error/panic.md
@@ -115,7 +115,7 @@ let home: IpAddr = "127.0.0.1".parse().unwrap();
 因此`unwrap`简而言之：成功则返回值，失败则`panic`, 总之不进行任何错误处理。
 
 #### 示例、原型、测试
-这些场景，需要快速的搭建代码，错误处理反而会拖慢实现速度，也不是特别有必要，因此通过`unrap`、`expect`等方法来处理是最快的。
+这些场景，需要快速的搭建代码，错误处理反而会拖慢实现速度，也不是特别有必要，因此通过`unwrap`、`expect`等方法来处理是最快的。
 
 同时，当我们准备做错误处理时，全局搜索这些方法，也可以不遗漏的进行替换。
 
@@ -138,7 +138,7 @@ let home: IpAddr = "127.0.0.1".parse().unwrap();
 
 当错误预期会出现时，返回一个错误较为合适，例如解析器接收到格式错误的数据，HTTP请求接收到错误的参数甚至该请求内的任何错误(不会导致整个程序有问题，只影响该此请求)。 **因为错误是可预期的，因此也是可以处理的**。
 
-当启动时某个流程发生了错误，导致了后续代码的允许造成影响，那么就应该使用`panic`，而不是处理错误后，继续运行，当然你可以通过重试的方式来继续。
+当启动时某个流程发生了错误，导致了后续代码的运行造成影响，那么就应该使用`panic`，而不是处理错误后，继续运行，当然你可以通过重试的方式来继续。
 
 上面提到过，数组访问越界，就要`panic`的原因，这个就是属于内存安全的范畴，一旦内存访问不安全，那么我们无法保证自己的程序会怎么运行下去，也无法保证逻辑和数据的正确性。