看一个武侠故事明白权限的那些事儿

　　在武侠故事里，功能权限和数据权限体系的解说由李平之口娓娓道来。
　　01：hr大理寺官衙的一棵古树下，一位青衣书生正拿着一篇案牍在读。丝丝凉风吹过，腰间的半片古玉随风飘荡。
　　启禀大人，您有一封来自蕊雪客栈的书信，落款是个红字
　　小吏双手捧着一封书信，恭敬地站在三尺开外。
　　噢？快快呈上。一听见来自蕊雪客栈，又是一红字，李平直接丢下了手头的案牍。
　　来，给我。李平嫌小吏呈得太慢，三步并两步奔到了小吏面前，一把抢过了书信。
　　权限看着书信，李平低声嘀咕了一句。
　　疾步走回房间，速速起草了一封回信，仔细卷好，封好火漆后，递给在门口等待的小吏。
　　用飞鸽回复，要快。李平说。
　　大人，这个不太？
　　你不用担心，照我说的做就是了，没事。
　　小吏领命前去。
　　许久未见，不知道红姑娘如今如何，听说仰慕者甚重呢，即是红姑娘所托，还需做更好的准备才好。想着这些，李平回到书桌旁，开始伏案书写。
　　蕊雪客栈二楼露台。
　　红姑娘取下飞鸽脚上的信件，抬手将信鸽放飞了回去。
　　他同意了呢红姑娘笑着扭头对旁边的木落说。
　　你还真是会替他考虑，也算是一举两得吧。木落微笑说道。
　　终于可以把这半块玉佩还给他了，他这么重情重义，让人家压力好大红姑娘嬉笑着摇了摇手里的半块古玉。
　　那可是人家为报救命之恩给你留下的好吧，也就你整天如此嫌弃木落微笑着摇头。
　　举手之劳啊，其实完全不用的，而且也完全用不上呢，还得老念着如何把它还回去红姑娘一付碎碎念心不甘的表情。
　　木落微笑着不说话。
　　如果其他人知道红姑娘还有如此小女儿的一面，估计都不敢相信吧。木落默默地想。
　　02：hr八月初八。
　　听说了嘛？今天似乎是一位大理寺大官来讲学呢。一个摇着扇子，腰跨宝剑的书生洋洋自得的说道。
　　红姑娘还真是手眼通天呢啧啧啧一个消瘦老汉连声吧嗒。
　　今天似乎要讲权限？这是什么鬼东西？一个浓眉大眼的大汉奇怪地嘟囔道。
　　你们懂什么，这可是律法底层的规则，你也不想想大理寺是干什么的，了解了这些规则，行走江湖岂不是快意很多？
　　这位姑娘说的不错，我看大家还是耐心等待着吧，来讲学的人中，又有哪次是让诸位失望的呢？
　　风公子说的有理。众人纷纷附和。
　　小姐，那人就是风公子，据说古道热肠，你说我们要不要二楼一位戴着斗笠的女客向旁边坐着的另一位女客说。
　　再看看，先看看今天讲的是什么吧。另一位女客回道，女客斗笠上的画字若隐若现。
　　只听外面一阵马嘶响起，众人纷纷探头看去。
　　只见一人青衣飘飘，面色如玉，身后还跟了一队素衣侍卫，虽是侍卫，却隐隐扑面而来一股凶煞之气。
　　哎呦，看起来来头不小呢，护送的人都是上过战场的呢。一个蜡黄脸的中年啧啧称奇。
　　只见青衣少年翻身下马，极为利索地走进客栈。
　　抬头望向站在二楼的红姑娘，神色极度认真，极为恭敬地鞠了一躬。
　　红姑娘微微颔首。
　　那就先开始吧，大家已经等了好久了呢。红姑娘微笑开口。
　　好。
　　青衣少年迈步走向客栈中央空出来的讲台。
　　在下李平，目前添为大理寺少卿，今日受红姑娘所托，前来讲授权限相关事项。
　　客栈中响起了一片嗡嗡声。
　　木落一拍额头，忘了让他不要明示自己的官位了
　　红姑娘抿嘴笑道：没事，这次带来的人看起来还不错呢，再不济，你到时候护送他回去好了
　　木落无奈摇摇头。
　　李平站着未动，台下渐渐安静了下来。
　　既讲权限，首先要明白权限是什么？
　　权限，一般是指系统设置的安全规范，主要用来控制用户仅可查看修改自己被授权的资源或信息。更多意义上是说，你需要控制某些用户只能做什么，不能做什么时，需要使用权限。
　　如果是开放式的，不需要控制，那么便完全不用权限。
　　既然要控制用户，那么一定是要管理的，只有管理才需要控制。所以，我们可以发现，在有管理诉求的场景下，会需要使用权限，在CRM、ERP、电商后台、企业服务（钉钉、企业微信）等涉及管理的系统，都需要有相应权限控制。
　　了解了具体应用的场景，那么我们先了解一下权限到底分为哪几类。
　　一般情况下，我们从功能和数据两位维度来将权限分为功能权限和数据权限。
　　李平随手递了一张图给旁边侍立的小二，小二张贴在讲台后面立着的板面上。
　　当然，这里也有必要解释一下什么是功能权限和数据权限。
　　功能权限，顾名思义，控制是否可以操作某些功能的权限，一般比如增加、删除、查询、修改，这类权限，我们认为是功能权限。当然，不同业务会有不同的权限控制，这里只是举一个例子。功能权限意味着，你页面上的任何一个按钮，都可以是一个权限。
　　数据权限，顾名思义，控制是否能看到某些数据的权限。比如有多个城市，可能某些用户只能看单一城市的权限，某些用户能看多个城市的权限；甚至某个城市分了多个区域，某些用户只能看单一区域的数据，这就是数据权限。
　　说完，又拿出了一张纸，小二恭敬接过，贴在了板面上。
　　了解了基础概念之后，我们来详细解说一下权限模块相关的结构和设计。
　　03：hr下面，我们先说功能权限部分，功能权限如果详细区分，还可以区分为页面权限和按钮权限。
　　这两种权限可以分开管理，也可以统一管理，由于性质基本类似，所以本次放在一起进行讲解。
　　小二将泡好的茶，端上了讲桌，李平含笑微微颔首表示感谢。
　　前面我们已经讲了，权限是用来控制人的。那么权限的结构就出来了，就是把权限赋予人。李平随手抽了最上面一张图递给了旁边侍立的小二。
　　一般情况下，对于小团体，或者成员不多，结构不复杂，其实这就足以满足诉求了。
　　当然，你们所了解的功能权限可能并不是这样，为什么不是这样的呢？因为如果仅仅只这样做，会遇到一些问题，我们接下来描述一个场景，你就大概明白了。
　　现在团体只有2个人，用的是同样的权限，你给每个人都分配了需要的功能。然后团体变大了，5个人、10个人、100个人、1000个人。假设每个人要配置的权限是20个，则每多一个人，则多出来一倍的量，人一多，怕是要哭晕在厕所了。
　　台下一片哄笑。
　　所以，在场景一的情况下，权限的配置会变得十分繁琐。不是十分合理，因为未考虑权限体系的扩展性，人一多，效率就会变得极其低下。且一旦有修改，你就需要每个人独立修改那时候怕是哭都哭不出来了李平微笑着继续开口。
　　台下又是一片笑声。
　　斗笠上带着画字的少女噗的一声笑出了声。
　　这人有点意思。她忙拿起茶杯，抿了一口说道。
　　因此，这种权限体系并不是特别友好，扩展性较低，那有没有更好的方法呢？李平并未受台下的影响，神秘一笑。
　　基于角色的权限访问控制，RoleBasedAccessControl，简称RBAC，今天我们讲功能权限的核心也是这个。
　　RBAC根据场景的不同，有多种变种方式，我们会根据场景逐一讲解，今天先讲最基础的RBAC权限控制。李平随手将手边的图纸递给小二。
　　在这套权限体系中，我们在原有权限结构的基础上，新增了一个中间值，叫角色。将对应的权限赋予相应的角色，然后把角色赋予给人，则人就会拥有该角色所拥有的全部权限。
　　李平随手又递了一张图，小二恭敬地贴在板面上。
　　一个权限可以赋予给多个角色，一个角色也可以拥有多个权限。一个人可以拥有多个角色，一个角色也可以赋予多个人，虽然他们是多对多的关系，但是请注意箭头指向，代表着谁赋予谁。人拥有角色，角色拥有权限。
　　这样看起来略有一些抽象，我们根据场景还原一下，这样会加深理解。
　　场景一：我朝约有1500余县，每县设县令，每个县令的权限都一致，约有50余项权利。那么此时我们如何做呢，我们只需要建立一个’县令’的角色，将对应权限赋予该角色，然后将人都配上县令这个角色即可。就可避免出现每个县令均需要配置50余项权利，只配置一次即可。
　　李平端起案桌上的水杯喝了一口，略作停歇。
　　场景二：一县令即将升任为刺史，但新县令尚未派遣，此时，该县令既需要拥有刺史相应的权利，也需要负责县令相关的事物，那么此时，就可以将’刺史’，’县令’两个角色均赋予该人，则该人即有用刺史的权利，也有用县令的权利。
　　（注：州为县的上级，一州约辖5县。百度百科）
　　场景三：前段时间朝廷刚发布公文，盐政不再由各个州县自行管辖，均收归国有，由国家直接管辖，那么县令将不再有盐政管辖相关权利，此时，我们只需要将县令角色中盐政管辖功能去掉，所有的县令均不再有该功能权利。调整会十分方便。
　　场景四：扬州刺史告老还乡，仅需将刺史之角色从该官员身上拿走，则该官员即无管辖之能，对其他刺史毫无影响，也十分便利。
　　李平略停顿了下，环顾四周，发现众人皆在仔细思考，微微一笑。
　　由此可见，RBAC权限架构体系，具有更好的扩展性和便捷性。那么讲到这里，RBAC的基础功能已经讲完了。
　　这部分架构已基本适用于大多数的团体，一般情况下已足够使用。当然，为了适应更复杂的场景，RBAC还有一些进阶版本，我们下面将开始讲它的进阶版本，以便于满足更复杂的场景。
　　讲完了RBAC的基础，李平忽然顿了顿，开口说道：诸位若对刚才讲的有什么疑惑，也可直接提出来，我们当场解答。
　　这套体系是否适用于所有团体？二楼一个窗口，一个穿着金色华服的少年若有所思的问道。
　　难道说乾通天下的少东家要拿这套东西管理自家的钱庄？一层大厅的众人议论纷纷。
　　赵公子还真是有想法，就是不知道他老爹是否会任着他胡闹。一个有着络腮胡子的汉子干了一碗酒说道，眼中隐隐约约透露出不屑。
　　可不能这么说，你还不知道吧，当年大陆两大钱庄争雄，一方败北，乾通天下开始雄霸大陆，据说背后完全是赵公子的手段呢，那时候赵公子才几岁？拿着扇子的书生一脸感叹的表情看着二楼说道。
　　你说的可是真的？络腮汉子一脸震惊。
　　真的假不了，假的也真不了，你且以后看着就是。书生明显不愿解释很多。
　　李平微笑着看向二楼。
　　这套体系经过朝廷这几十年来的验证，几乎可适配任何团体。不过
　　不过什么？赵公子追问。
　　不过每个团体都有自己团体独立的管理手段和方法，并不是所有团体都跟朝廷体制一样。因此，对于不同团体，还需要在该理论的基础上做一些扩展，让这套理论能够和自身团体的管理方法相结合，才能更好地发挥作用。
　　赵公子若有所思地点点头。
　　李平收回了目光。
　　刚才所说的架构已经基本适用于所有团体，当然会有一些进阶的结构用来适应于更多的场景，我们将对这些较为复杂的场景逐一讲解，以便于大家更好的理解这套体系。
　　目前每县设县令一人，师爷一人，捕快三人，每人权限不同，有大有小。按照我们上面的结构，县令有县令的权限，师爷有师爷的权限，捕快有捕快的权限，分别独立设置即可满足。
　　李平将一张图递于小二。
　　场景五：县令有县令的权限，师爷有师爷的，捕快有捕快的，很完美。但是也会有一些小问题。前段时间朝廷取消地方盐政管理的相关权限，那么县令的权限要调整一遍，师爷的权限也要调整一遍，在角色不多的情况下，一切都还好，若有大量角色时，依然会十分繁琐。
　　那么有没有更好的方法呢？李平笑着看了一下四周。大家似乎都还挺感兴趣。
　　然后，他抽出一张纸递给了小二。
　　我们可以在角色上增加层级的概念，上层角色会自动拥有下层角色拥有的全部权限。同时该角色也可以有自己的独立的权限，最终上层角色的权限集合是所有权限的并集。
　　在这种方式下，就会较完美的处理上面这种场景的问题，取消地方盐政权限，直接将师爷的权限取消，县令自然就没有相关权限了。这种方式，叫做继承。即上级角色继承下级角色的功能。李平停了一下，以便于大家理解和消化。
　　当然，这里涉及到了一个角色层级的概念，其实本质上是组织架构，就像我朝现在的组织架构一样，不过这些目前暂不是重点。后面有机会会再单独讲组织架构相关内容。
　　这种较为复杂的场景讲完了，我们来看另外一种场景。
　　小二拿着茶壶走了上来，默默地将水杯里的水加满。
　　场景六：我是大理寺少卿，平时一般负责审理相关案件，前段时间，有人在御前参了我一本，状告我重重罪行，最终该案件被移至大理寺评审。
　　还有这等趣事？木落听到后笑道。
　　在皇帝面前状告他的儿子，也真是佩服朝中某些人能做的出来。红姑娘笑着说。
　　毕竟此事知者甚少，也难怪，短短几年走完别人要走一生的路，皇帝偏袒的有点过了，也怪不得别人试探。木落意味深长的说。
　　红姑娘笑着看了木落一眼，没有说话。
　　虽然我为大理寺少卿，但我已身涉案件，自然不能再做审理。李平环顾一周。
　　说道这里，大家应该都大概明白了，一个人不能既是被告，又是法官。在这套体系中亦如是。因此，面对这种场景，体系中应该有明确冲突的角色限定。即若你是某个角色，你就不能是另外一个角色。
　　小二很自觉地前去接过李平手中的图纸。
　　因此，在有必要的情况下，还需要在权限体系中去定义互斥类的角色，以避免某天真的出现了既是法官，又是原告的尴尬情况。
　　台下一片哄笑。
　　对于限制性，除了避免出现冲突的角色分于同一个人之外，还有一种场景需要诸位考虑。
　　场景七：每天开始的时候，县令有自己的一堆事情要做，批改文书，审理案件，捕快也有自己的一堆事情要做，抓捕犯人，例行巡逻。你会发现，虽然县令拥有所有的权限，但是对于他自己本身的工作而言，在他的工作台中，他需要关注的内容和捕快需要关注的内容是不一样的。
　　你没办法要求县令每天上街巡逻，你也不能让县令去处理捕快的工作，因此，在整个权限体系中，在某些特殊场合下，还需要定义角色的优先级，或者仅允许一个主要角色进行处理。
　　李平喝了一口水，台下众人皆若有所思。
　　定义角色优先级指的是，若你既是县令，又是捕快（即权限工作出现重叠的时候），你需要按照县令的身份，去处理县令的工作，批改文书，审理案件。县令这个角色的优先级比捕快高。
　　当然，如果你作为一个县令，一定要去实际体验捕快的工作的话，那就在工作台中切换角色为捕快，那么此时就会告诉你县城里有哪些街道需要巡逻，哪些犯人需要抓捕。
　　李平缓缓将杯中的水喝完，给众人留了几分钟思考的时间。
　　那么，在权限体系已经到了这种情况下，是否还有可以提升的地方呢？
　　台下议论纷纷，都这么多场景了，应该没有了吧。
　　赵公子眉头紧锁，似乎觉得已经能解决所有问题，但是又感觉似乎还缺点什么。
　　似乎，如果职位切换比较频繁的时候，还欠缺了点什么？赵公子不太确定地说道。
　　李平深深的看了赵公子一眼，心道，这少年果然不一般。
　　诚然，这里面其实还有更深的两层可以考虑。
　　场景八：我朝每年都会派遣一批人，作为监察御史，分东南西北四方体察民情，大事奏裁，小事立断，政事得失，军民利病，皆得直言无避。这些监察御史平时都有自己的职责和角色，在分派去往不同方向巡查时，需分配给每个人相应的权限，在巡视结束，有需要将每个人相应的权限收回。由于巡查人数众多，虽然有权限体系支持，但依然过于繁琐。
　　李平略作停顿。
　　因此，基于此，我们引入用户组的概念，我们设立‘监察御史’组，给监察御史组分配了‘监察御史’的角色权限，然后将所有成员拉入‘监察御史’组，则该成员自动拥有‘监察御史’组所拥有的权限。等任务完成后，直接将成员清除该监察御史组即可，对应成员自动失去监察御史的权限。通过这种方式，更加方便地管理。
　　小二从李平手里接过一张图贴在了板子上。
　　基于此，基本上功能权限体系已经讲完了。
　　04：hr但是，权限这套体系是否真的是能解决所有问题？他的优势在哪里？劣势又在哪里呢？
　　RBAC权限体系依据角色为载体，更加方便所有成员权限的管理（新增调整），这是一个巨大的优势，但请一定关注，这套体系是用来更加方便的管理权限的，它不是权限本身。
　　那权限本身是什么？一个黄脸汉子直接开口问。
　　李平笑了一下，还未说话。
　　李公子刚才已经说了，对应功能权限而言，你的页面，你页面上的任意一个按钮，那才是权限。风公子倒是接上了话。
　　黄脸汉子脸一红，默默地低头喝水。
　　那劣势是什么呢？看到问题已解决，李平继续说道。
　　RBAC是基于角色的一套体系，那么既然是基于角色，那么角色一定是个最小单元。那就意味着，同一角色的权限一定是一样的。但是，实际上是否真的是一样的呢？我朝1500余县，每县皆有一位师爷，但是每县的师爷拥有的权限一定相同么？
　　林业比较发达的县，师爷要关注林业，而无林业，却有渔业的县，师爷要关注的渔业。两方资源都有的，师爷也需要关注两方。所以，虽然RBAC带来了极大地便利性，但在同时也丧失了一部分灵活程度。
　　我们要知道，直接把权限赋予人，即最基础的权限管理，虽然维护和管理起来十分费事，但却也最自由。
　　因此，是否有可能将RBAC和最基础的权限管理结合一下呢？李平微笑说道。
　　这个问题就算是留给各位的思考题了，若有所得，也可相互间交流一番。消息留在客栈即可，我收到后自会回复。
　　李平端起水喝了一口，茶杯还未放下，就接着开口。
　　05：hr功能权限讲完了，我们来说一下数据权限。
　　既然说数据权限，那就需要明确一下数据的概念，这里的数据并不是你能看哪个页面不能看那个页面的意思，那个是页面权限，跟数据权限没关系。
　　那么数据权限到底是什么？我举一个例子大家就明白了。每个县每年的征兵数据、田赋数据、人口出生和死亡数据，都由每个县独立管理，其他县无法获知其他县数据。刺史因为下辖五县，因此他能知道下面五个县所有的数据，但刺史也并不知道其他州的数据，逐级向上扩展。
　　所以，数据要确认的是能看到的数据范围。李平抬头看了赵公子一眼。
　　就像对于乾通天下，各个地方的掌柜，也只能掌握自己钱庄的收支、借贷和利润，而不会知道其他钱庄的数据，而对于负责一整个区域的大掌柜，则可以看到其区域所有的钱庄的数据，而对于少东家，就能知道所有的数据。
　　赵公子点了点头。
　　那么对于数据权限，如何处理呢？李平微微抬头，望向台下。
　　听李公子举的几个例子，数据权限涉及到层级，层级越低的人看的越少，层级越高的看的越多，那就是跟组织架构有关了？风公子站起来说。
　　李平笑着点点头。
　　风公子说的不错，确实跟组织架构有关。当然也会有其他方式，我们先讲一种简单的方式。
　　李平递给小二一张图，小二顺利接过。
　　这种方式与基础的功能权限有点类似。即将每个县的数据，都作为一个点，如果是某县县令，则分配对应县数据，对于刺史，就分配五个县的数据。
　　台下人纷纷摇头，这样太麻烦了吧，1500余县，要死人的。
　　李平静静的听着台下的讨论，并未开口。
　　台下讨论一会后，慢慢的安静了下来。风公子的眼中似乎有了一丝其他的神采。赵公子也忽然扬了扬眉毛。
　　其实，对于大多数团体，没有太多区域的时候，这种方式可能才是最灵活，最简单的。除非已经扩展到了很大的区域。毕竟不是每个团体都跟朝廷一样的。
　　台下人均点点头，表示认可。
　　那么若区域很大的时候，应该如何通过数据权限管理呢？赵公子忽然问道。
　　如果说基础的数据权限管理和功能权限管理是类似的话，那么解决数据权限的思路是否也跟功能权限类似？风公子忽然接到。
　　李平望向风公子，暗叹，果然不愧是能以一己之力在江湖闯下偌大名头的风公子，聪明绝顶，一点就通。
　　风公子说的没错，他们确实是类似的。上面已经提到了，数据权限很依赖层级，那么组织架构就需要大概说一下了，其实比较简单。
　　李平伸手向小二递出了一张图。
　　组织架构相对比较好管理，更多的是一个部门间的层级关系。那么数据权限本身是什么呢？
　　数据权限包括：全部数据，本部全部数据，本部及子部全部数据，本人全部数据，本人及下属全部数据。这里需要简单解释下这几种数据权限的含义。李平环顾了一下四周。
　　台下众人皆是眉头紧锁。李平心道，果然数据权限虽然解释起来很简单，但真正落地理解时还是会有很大难点。
　　数据权限本身与层级结构完全没有关系，是独立于功能权限和组织架构之外的一套体系，但由于它跟层级又有紧密联系，所以，它与组织架构又紧密相连。
　　全部数据指的是全部的实际数据，这是一个无比慎重的权限。只要将该权限分配给任意一个人，他就能看到全部的数据。哪怕分配给一个县令，它也能看到我朝全部的数据，因此，这个数据权限分配时要非常慎重。
　　李平低头喝了一口茶，发现茶有些凉了，就随手放到了桌边。
　　小二看到，里面上前端走去换新茶。
　　本部全部数据，即意味着可以查看本部的全部数据，对一个县令而言，就可查看自己县全部的数据。
　　本部及子部全部数据，即意味着可以查看本部及附属部的全部数据，对于州长官刺史而言，就需要可以看到州的数据和下属五个县的数据。
　　李平接过新茶，饮了一口。
　　敢问先生，那本部全部数据和本部及子部全部数据，这两个数据权限有何区别呢？二楼戴着斗笠的女子起身施了一礼，问道。
　　李平环顾了一下四周，发现大多数人皆有疑问。
　　这是个好问题。就以扬州为例，扬州刺史除了负责扬州本城所有数据信息以外，也需要负责下辖五县的所有数据信息。而对于扬州刺史下属的判司等职，其实只需要关注扬州本城的所有数据，那么在此时，他们仅需要本部的全部数据，而无需去负责下辖部门的所有数据。这就是这两种数据权限的区别，会让数据的管理更加灵活一些。
　　众人听后，略作思索，纷纷点头。
　　那对于个人数据和个人及下属的数据就比较好理解了。对于一个捕快而言，他抓了哪些囚犯，哪些审讯的结果如何，每个捕快只需要关注自己的数据即可，其他捕快的数据可能并不需要对其开发，他也不需要了解。而如果捕快需要助手的时候，助手处理的信息其实该捕快也需要关注。
　　当然，在这里引出了一个助手的概念，那么在成员管理的时候，就需要能在体系中明示这个人的助手是谁，是否的话，这个权限就与个人数据权限是完全一致的。
　　数据权限本身已经说完了。那么到底如何管理呢？
　　李平递了一张图给小二，小二恭敬的贴在板子上。
　　其实跟功能权限很类似，功能权限中我们用角色承载功能权限分给成员，在数据权限中我们用职权承载数据权限分给成员。当然，在不同的团体中，是叫职能还是职权还是其他的，就看怎么理解起来更顺畅了。
　　数据权限讲到这里，基本上也就差不多了，但还有一点需要大家关注，对于上面所说的赋税、人口等信息需要数据权限控制，那么对于朝廷对外发布的公文是否也需要数据权限的控制呢？
　　这个自然是不用的，这本来就是给所有人看的。摇着扇子的书生回道。
　　嗯，所以，到底什么样的数据需要使用数据权限控制，也是需要定义的，这点勿忘。李平道。
　　这里有一张图可以明确表示功能权限和数据权限的应用，可以看一下，加深理解。
　　李平递了一张图给小二。
　　权限体系讲到此就差不多了，多谢各位聆听。李平站在台上向诸人施礼。
　　06：hr李平正待抬步走向二楼红姑娘的位置，忽然一个侍卫进来进来对其耳语了几句。
　　李平听后眉头一皱，随即立在当场，抬手向红姑娘方向说道：今日幸不辱使命，原想多逗留几日，但皇城似乎发生了大事，待我处理完后再前来赔罪。我这里留下了一些实际使用时的部分书稿，若有兴趣，也可分给众人。
　　说完，不待红姑娘回复，便快速转身离去。
　　刚好卡在这个点上，是担心我们与其接触么？红姑娘微微笑着望向木落。
　　木落摇摇头，叹了一声。
　　我走一趟吧。说完飞身下楼。
　　接着这个。红姑娘丢出手中的半块古玉。
　　木落反身接住，径直出了客栈。
　　人潮开始渐渐走出客栈，风公子也站起身来，向红姑娘走去，似要告别。
　　小姐，你再不下决断，风公子就要走了戴着画字斗笠的一位女客对旁边的女客说。
　　旁边的女客，眼神慢慢由犹疑变为坚定，站起身来