From 458b02d45b4dd65f37a7f77c0c22aaa2bb7816d0 Mon Sep 17 00:00:00 2001
From: scwang18 <45680124+scwang18@users.noreply.github.com>
Date: Sat, 3 Aug 2019 22:12:51 +0800
Subject: [PATCH] Update blademaster.md

---
 doc/wiki-cn/blademaster.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/wiki-cn/blademaster.md b/doc/wiki-cn/blademaster.md
index 3ac7de262..c656045e1 100644
--- a/doc/wiki-cn/blademaster.md
+++ b/doc/wiki-cn/blademaster.md
@@ -9,7 +9,7 @@
 
 # 设计目标
 
-* 性能优异，不应该惨杂太多业务逻辑的成分
+* 性能优异，不应该掺杂太多业务逻辑的成分
 * 方便开发使用，开发对接的成本应该尽可能地小
 * 后续鉴权、认证等业务逻辑的模块应该可以通过业务模块的开发接入该框架内
 * 默认配置已经是 production ready 的配置，减少开发与线上环境的差异性
@@ -30,7 +30,7 @@
 
 `blademaster`处理请求的模式非常简单，大部分的逻辑都被封装在了各种`Handler`中。一般而言，业务逻辑作为最后一个`Handler`。
 
-正常情况下每个`Handler`按照顺序一个一个串行地执行下去，但是`Handler`中可以也中断整个处理流程，直接输出`Response`。这种模式常被用于校验登陆的`middleware`中：一旦发现请求不合法，直接响应拒绝。
+正常情况下每个`Handler`按照顺序一个一个串行地执行下去，但是`Handler`中也可以中断整个处理流程，直接输出`Response`。这种模式常被用于校验登陆的`middleware`中：一旦发现请求不合法，直接响应拒绝。
 
 请求处理的流程中也可以使用`Render`来辅助渲染`Response`，比如对于不同的请求需要响应不同的数据格式`JSON`、`XML`，此时可以使用不同的`Render`来简化逻辑。