银行核心系统入门简介

《银行核心系统入门简介》由会员分享，可在线阅读，更多相关《银行核心系统入门简介（7页珍藏版）》请在装配图网上搜索。

1、银行核心系统入门简介（2）5.2 计息有的系统可能没有把计息单独列为一个模块，而是直接嵌套在各个业务模块之间 了，不过设计成一个模块，个人认为可能会显得比较专业一点，至于到底好不好用那就见仁 见智了。 刚接触银行业务的时候，曾经很执着，很傻很天真的想过活期账户到底是怎样计息的，因为 定期账户的计息方式相对简单，余额乘天数就对了，但是活期账户的余额是常常在发生变动 的，所以前20 多年我一直都不知道银行每年给我算的活期利息到底对不对。 银行会计上，通常都会通过“积数”这个东西来计息。何谓积数？就是余额天数，所以积 数的单位应该是“元 天”比如说 利息 = （账户余额天数利率）/ 360，在这个公

2、式里，账户余额天数就等于 积数，于是这条公式也可以写为 利息 = （积数 利息） / 360。 定期账户因为账户余额通常不发生变化，所以一般不会涉及到积数。 活期账户采用动户累计积数的方式来计息。也就是说账户余额没有发生变动，就什么事都不 干；当账户余额需要发生了变动时（比如说取款），那么业务模块里就将上次账户变动日， 到当前日期的天数计算一算，然后用变动之前的账户余额乘以这个天数，然后把这个积数累 加到之前的积数上。最后计息的时候，就使用这个积数乘以利率再除360。 在设计的时候，就需要把每次账户变动的日期都登记下来，还需要有地方记录账户的当前积 数。对公计息，或者是一些需要计息内部账，有可

3、能是每天计积数，也就是每天把账户余额累加 到积数中。之所以这样设计，是因为对公以及内部账户的数量远小于对私账户，每天把每个 账户都过一遍，花不了太多时间；而要是每天把储蓄账户都过一遍，就有点类似于结息了。 （对私账户多的银行，有可能达到上千万户，尤其是些代理了社保，医保的银行，不可小看） 不过现在有些很好很强大的国外系统，对于利息的处理，是每日计提，当然，这样设计也应 该会有它的独到之处。刚才这里提到的了需要计息的内部账，那么一般而言，什么样的内部账需要计息呢，我想， 应该是不同法人之间上存下放的款项需要计息。对应于一般的商业银行以及统一了法人的信 用联社，因为全市是一级法人，可能就没有需要计

4、息的内部账了。而对于没有统一法人的联 社，因为每个信用社都是一个独立的法人，那么信用社存放在联社的用来做往来清算用的资 金，就是需要计算利息的。还有的银行，对于贷款的处理，也会有资金池的概念，这时总行 下拨分行的用于贷款钱，也是要计息的。这里可以看到，对于计息模块而言，积数是一个很好用的东西。积数除了计息，还有很多其 它的用途。比如说招行的金卡，说的是“日均存款5 万元以上不收取账户管理费”，那么， 这个日均存款5万是如何判断呢，我很久以前曾经问过一个大堂里的MM （跟我同姓喔，惜 乎已经有BF 了），她说是根据积数来判断的，也就是每个月需要增加150万的积数，这样听 起来就很合理了吧。对于某

5、些业务来说，可能需要登记利息的明细。比如说贷款的复利的计算，就是根据利息来 的。无论是正常贷款，还是逾期贷款，都会生成利息。生成的利息如果未及时归还，则会再 根据这笔利息生成相应的复利。复利的复利，喔，太可怕了，也还是视为复利吧。总之，我 的意思就是说，储蓄、对公账户这样的结息，在计息模块中可以不用登记利息的明细，因为 最后结息的时候根据积数一次搞定；而对于贷款（或者是其它有需要的模块），可能需要在 每一笔利息产生之后，都把它登记下来，已保留行使进一步措施的权利。除了贷款之外，还有一些定期账户，也最好采用明细的方式进行处理，越细越好，比如什么零存整取，教育储蓄之类的，要是没有详细的每期存款登记

6、，漏存登记等等，是很容易就被 它玩死的。通知存款以前觉得它很可怕，现在想想，突然又觉得没那么可怕，无非就是通知取款，通知 期限内的积数登记，然后取款又或者取消通知。可能最主要的，就在于通知期限内的积数计 算。总之提取一个计息模块，为这类业务特别定制一些明细文件是很好的一个选择。 提到计息，也就顺便说一下利息税。国家在这十年来，调整了两次利息税税率，一次是涨成 两分，一次是降成五厘，就那么一点钱，调来调去累不累，要收就收，不收拉倒，还搞什么 分段计税，烦死个人。在这里，不知道有没有人是负责搞利息税这部分程序的，也不知道去 年改这部分程序的时候，有没有很不爽过。其实要是早考虑到这种情况，倒是可以一

7、开始就 通过设置利息税参数表，然后修改计息程序，读取利息税参数表，最后根据不同阶段的参数， 分段计息算税。这个方法倒是可行的，也实现过，对于整存整取的定期来说，算得上是一劳 永逸，不过对于活期而言，每次调整利息税税率的时候可能就要搞一次类似于结息的东西了， 好象没有一劳永逸的方法。在国外的先进系统中，还有一种精采的倒起息可以让人一筹莫展。这种玩法的意思，就是说 当客户来柜台前做个什么交易的时候，允许账户的起息日期在业务发生日之前。比如说有人 7 月 14号来到柜台前还一笔贷款的款，然后说我这笔钱明明7 月7 号就到账上了啊，为什 么银行不给我扣，非得让我贷款逾期之类的话。然后核查，如果属实，那

8、就倒起息一把，现 在虽然是7 月14 号，但还是当它是7 月7号还的。（好象是这样，也可能是我说错了，大家 对这段解释千万不要太放在心上）总之，如果有倒起息的需求，那必须在最开始设计的时候 就与其它计息，以及业务流程整合在一起来考虑，如果中途加入这个需求，那改起设计来会 比较费劲，改起代码来更是难上加难。最后，我们再来说说计提，这个也和利息有关。计提常用于利息支出，比如说利息支出是 5211，5 字头，即是一个用于营业收支的损益类的科目。计提的会计分录中，对应的科目是 应付利息2611， 2 字头，是一个负债类的科目。所以说，计提的含义就在于，虽然当前客 户利息并未产生（是结息的时候才产生），

9、但是这笔利息（尤其是整存整取的定期利息）迟 早是会产生的，所以这里预先计算，或者说估算出营业支出，计到负债的科目上（负债嘛， 本来不属于银行的钱，迟早是要被取走的钱），然后到这类账户结息的时候，就直接从应付 利息中支出，计到客户账户上，而不走利息支出这个科目了。看懂了吧，这里其实也就包含 了管理会计中的概念，实际上是产生一个提前测算成本的动作。诸位搞IT的朋友们，你们 看过会计学原理吗？这部分模块一般没太多可讲的，通常的设计，都是搞个主文件，保存 针对每个账户的信息（比如说账号，账户余额，当前积数什么之类的，总之就是与账户有关 的信息），然后再搞个账户明细，用来记录每个账户发生过的业务。听闻有

10、的系统设计，不 知道是不是考虑到锁表的问题，计划取消主文件，直接上明细，愕然之余只能感叹自己见识 浅薄，因为我总觉得明细要考虑冲账的问题，在读取上不如主文件一下搞定那么畅快。而且 主文件可以有锁表保护，可以更好的保障数据的正确性。 所以私底下，我还是很推崇这种“主+明细”的设计方式。以前曾经很无奈地见过有人在新 增业务模块时，把主文件和明细混在一起来搞，于是整个业务流向怅然若失，需求有变动时 改动几乎无从下手，若非我多年功力，是断断不可能在加两天班后就理顺通过测试的。 说起储蓄呢，又忍不住再提一下招行，不可否认，它的一卡通做得真的挺好，本外币，定活 期，一张卡全部搞定。我以前就经常把活期转成三

11、个月定期。根据我本人看法，三个月定期 从利率差与时间存放差上来说，性价比是最高的，也就是说一年期利率虽然高，但很难保障 这点钱在一年内不用。所以推荐大家把5K以上的存款转成三个月定期，一般忍忍也就可以 拿到利息了，当然了货币基金也是一个不错的选择。还有一次自做聪明搞了个一年期的零存 整取，性价比不高，而且还得到柜台去办取款手续，把自己麻烦死了，不推荐使用。 扯远了，其实本来是想说，活期、定期、外币账户，这些都是一个又一个的账户，而在招行 的设计之中，这些账户，都会与我们的那一张小小的卡片关联起来。换句话说，人家的卡号， 应该只含具体的卡的信息，比如说卡的有效期，密码，磁道信息什么之类的，不直接

12、对应某 个具体账户的；而各个具体账户则应该会有一个与卡号的对应关系。然后到寄对账单的时候 啊，打电话介绍买保险等等附加服务的时候，就还是根据卡号来提供服务。不过还是要根据 账户的资金流动来分析消费习惯，以及贡献度的高低等等。至于怎么实现，就根据各位自己的核心系统慢慢体会，不过这么多年了，也可能大部分银行 都实现了这种功能或者是类似的一卡通，那就当我这段没有讲过吧，总之我觉得这种理念很 好很强大，让我用得觉得很方便。至于对公，好象就更加没什么可说的了。5客.4 户信息客户信息，卡号，账户号，这三者是层层细化的关系。所以说，整合 好三者的关系也是一个不容易的事情。 在我见过的几套系统之中，最常见的

13、问题，就是同一个客户对应多个客户信息。这通常又是 个历史遗留问题，比如在手工或单机年代，开户时对于身份证明证件要求不是很严格，一个 人可能开了很多账户，还可能是用化名开的账户。在移植上线的时候，常常由于重要信息不 齐，又要考虑客户层面的因素，很少能强制性补齐客户资料，通常只能在移植时自动生成一 些客户信息，这样就造成了很多冗余，而且也不好再做深层的数据挖掘和客户分析。相比较 而言，新开立的分行可能这种情况会好一点，而且面对的客户高端一点的，又会更好一点。 在新系统上线，做数据移植的阶段，一般客户信息的问题是最先体现出来的，通常新系统会 要求得比较理想化，而实际情况千奇百怪。这里说说常见的，比如

14、说新系统一般会要求证件 号码唯一，但是因为很多客户的证件信息缺失，所以这个号码唯一可能会有困难；再比如说 有时可能会出现证件号码重复，而且还真的不是同一个人。 总之这些问题，它不是新系统的错，也不能完全说是旧系统的错，最关键的是在移植的时候 如何处理利用好这部分客户信息。 再一个问题，就是客户信息的更新。个人认为最好能有一个有效的途径来更新客户信息，尤 其是工作单位，电话号码，对于很多流动人员来说，经常会变换。如果每次都要来柜台更新， 我想那基本上就可以认为它是形同虚设了。 可以说，随着现在以客户为中心的概念的提出以及越来越多的实现，客户信息这个模块也应 该会越来越受到重视，以前设计的表结构应

15、该会有些不够用了。目前如果没有新系统要上的 同行们，恐怕是要等着改结构加字段了，保重。5贷.5 款很多地方都会把一般的商业贷款与按揭贷款和消费贷款（比如车贷、分期付款之 类的，总之有点类似于按揭贷款的）区分开来，这样自然有它的道理。我在这里只谈我个人 的设计方案。 现在的商业贷款常常采用一笔发放，一笔回收的概念（当然有时会有提前还款，但不象按揭 贷款这样有个具体还款计划），然后用合同号，或是借据号做为贷款的一个类似于唯一关键 字这样的东西。但是有时公司的商业行为中，一个大项目里会包含多个子项目，然后对应不 同的子合同，这些合同对应的贷款之前其实都是有关联的，尤其是在算逾期什么之类的时候， 有的

16、是一逾全逾，有的又不是。所以我个人觉得，贷款最好做成多笔发放，多笔回收的形式， 发放与回收不必一一关联。但最好在贷款录入时（这时不一定已放款），就录入相应的还款 计划。贷款的账号，最好与具体的业务信息剥离，类似于储蓄里面“一卡通”的概念一样，每个贷 款，有它自己独立的贷款号，然后正常、逾期、两呆，以及相应的利息账号都与这个贷款号 关联起来，便于以后的跟踪追查。而对于按揭贷款来说，因为期限长（常常是二三十年），而且比较具有规律性，所以一般就 不用列出还款计划的明细了。不过要注意，一般按揭贷款的首月还款是按天算息的，稍微注 意一下就可以了。最后，特别强调提出一点，见过两家行，都推出过“等本等息”这

17、种经典的业务产品，也就 是客户每月按等额法算出的金额还款，但本金的计算则按等本的方式来算。这里要大声疾呼，这种东西从原理上来说就已经是错误的！因为同样金额，同样期限的贷款， 等额法的利息是要大于等本法的利息的。等本法计算方便，理解简单；而等额法是数学家们 经过精确的计算，推导出公式，最后计算出的一种还款方法。也就是每个月的还本、还息都 要严格按照计算出的公式，这样才能达到等额的效果。试想想，这个月还了一定的本金之后， 下个月计算出的利息就不一样了吧，这时要求下个月还的本金与还的利息加起来还是和这个 月的一样多，而且还要求每个月还的本金加上利息都是一样多。所以，除非是数学学得特别 好的同学，咱们

18、一般的程序员不要妄想自己能推导出公式来，照着公式算就行了。如果强行 按等额法计算出的钱来制订还款计划，又按等本法的方式还计算每期还款本金，虽然是方便 了，但是在每年利率变更，重算利息时，必然会导致利息总和由等额法的利息渐渐趋近于等 本法的利息，也就是总利息额将会越来越少，于是要么在本金与利息的问题上无法自圆其说， 要么可能会出现利率上调还款金额反降，甚至负利息的问题，不可不查。5.6清算与结算清算与结算本来是两种业务，不过因为结算中通常又会包括清算， 要分成两小节，每小节又说不了太多话，所以干脆放在一起算了，而且这一节只谈流程，不 讲设计，这种业务流程理顺了自然就可以设计了。 先约定一下，商业

19、银行的级别，一般是 分行支行两级，有的可能还会有储蓄所这种第三 级。简化起见，暂时就分两级来说吧。如果对应到信用社，那就是联社营业部信用社营业 部。分社一级省略。先从结算说起，这里的结算业务，指的就是跨行转账，至少我是打算这么说。每家商业银行， 都会在当地的人民银行有一个资金账户，可以理解为结算业务用的备付金账户。然后在自己 行内，也会开立一个与之对应的“上存人行款项”的账户。理论上，人行的这个账户和我们 自己行内的这个账户，表达的都是“该银行存放在人民银行的钱”的这个意思，所以金额也 应该相等。那么，这两个账户在不同的银行（也即不同的系统中），如何保障它的一致性？ 这一般就是通过日终，营业终

20、了时的对账来保障。所以对账是很重要的，这个后面再说。 至于结算业务的流程，先从遥远的手工账/单机账年代说起吧。在那个时候，结算的途径、 概念、术语可以说是五花八门，什么先直后横，先横后直，提出借方，提出贷方，提入借方， 提入贷方，信汇，电汇等等等等，不把人转晕誓不罢休。现在好象大小额支付横空杀出，倒 是简化了不少。当然也还有行间转账，同城支付，省金融平台，不过概念上渐渐趋向统一化， 先不多说，先谈谈当时我理解中的流程： 首先如果要转账，我们要在柜台前填一份一式五联的单（一定要用力填哟，不然最后一张纸 上看不到什么字迹的），然后这笔钱就从我们的账户上扣下来，划到银行内部的某个往来账 户上了。然后

21、这些单据，再手工传递到上一级，上一级再手工传递到人行（当然，也可能上一级就是 人行，这里不要太较真），每传一次，这笔资金都会在当前做业务的这一个银行的往来账户 中流动，最后通过人行，流到你想转入的银行中，那个你手工填的单，也流到那家银行中。 最最后，转入行的业务人员核对单据，账号，户名都没问题，这笔钱就从往来账户划到我们 所填的转入账户上去了。在这些过程中，结算的同时就已进行了清算，资金的流向是A银行的某支行dA银行的当地分行dA地人行dB地人行dB银行当地分行dB银行的某支行 也就是每一笔转账，在行间的这一步，都是通过它们在人行的资金往来账户，实现了资金的 流动。如果是上述的资金流向，就叫先

22、直后横。如果是A地人行dB银行A地分行dB银行B地分行 dB 银行某支行这种方式，就叫先横后直。这些单据的传递，都是手工的，或者说是落地的。如果是用信件的方式传递，那就是信汇； 如果是用打电报的方式传递，那就是电汇。手工的传递都是有场次的，比如一天两场，或是 一天一场之类的。所以这个转账的效率有多快，我就不说了。现在科技进步了，手段丰富了，社会于是也就和谐的。先从我个人较为欣赏的大额支付说起。 我一向认为大额这个业务设计得是相当的合理，因为资金是点对点，清算行对清算行，大大 缩短了流程，更重要的是，信息的传递是自动的。还是上述的CASE,假设转出行与转入行 都开通了大额业务，那么资金的流向是：

23、A银行的某支行d人行dB银行的某支行原则上是这样的实现，当然行内的设计怎么处理我们就不多考虑了。行内当然也可以设计成 为先从 A 银行的支行转到上级分行然后再发出，总之人行收到一笔大额的转账信息之后， 是会自动、直接发向指定的转入行（假设转入行也开通了大额业务的话） 大额系统的对账，不考虑具体的客户账户，只考虑清算行。通俗的说，人行只管 A 银行今 天给B银行转过去多少钱，转过去了，人行就不管了。至于B银行什么时候把这笔钱入到 客户账户中，那是 B 银行的事，人行不管。听起来责任还是很清晰的吧，而且这样也有助于 减少账户锁表而造成的行间转账失败。因为大额的这种设计，所以实际转账中，几乎是实时的

24、。我从某地信用社转到异地招行，在 柜台还没最后签字，收款短信已经来了。因为大额业务发生的时候，是支行对支行的，所以每发生一笔业务之后，实际上这笔资金是 暂时体现在该支行的某个行间往来账户上。所以每天大额业务结束后，还需要按清算的流程， 将这笔资金按往、来分别清算到上一级分行（或是总行吧，总之就是当地的最高节点），然 后分行与人行发下来的电子对账文件进行对账，检查汇总往、来数、金额是否相等。如果相 等，那就可以把往来一轧差，转出多的时候就从存放在人行的账户里扣钱，转入多的时候就 往那个账户里加钱。至于这个清算的步骤，通常还是由手工发起，不过这里的手工，就不是指传递单据，而是指 运行程序。当然，清

25、算程序也可以自动运行，这个根据系统的不同，要求的不同，自行调整 设计。5.7额度控制和计息类似，可能有的系统没有把额度单列为一个模块来处理，而是 仅仅作为业务模块之中的一个判断项。早期的业务中，的确可以这样处理。不过随着现在金 融产品的不断推出，我个人认为还是把额度拿出来单独搞一下会更好处理一点。 比如说，一个账户，可能会有几次冻结，也能会有多项额度控制，每次的解冻，又或者是解 除控制，都可能会对账户的额度造成不同的影响，如果夹杂在业务模块中，字段的设计，状 态的控制可能都会有些问题，单独整成一个模块，或者说是一个大公函，在账务交易（或是 账务模块中）的时候，用额度模块来进行一下判断，可以更方

26、便的检测账户的可用额度是否 足够。另外，一些账户相关的透支什么的，也可以比较好的按客户来处理，而不是针对每个账户设 置是否允许透支。以至于循环授信额度，这些概念都可以拿出来使用，简单的来说，有点类 似于储蓄卡向贷记卡的管理方式倾斜，不过我没做过贷记卡，所以这里也提不出太多东西， 只好拿个概念出来大家一起参详一下。5.8 冲账本着想到哪里就说到哪里的原则，刚才突然想起冲账还没有说，那么这里就说说冲账。 冲账的概念前面已经提过，这里我们指的，就是红字冲账。因为蓝字冲账就是再做一笔别的 账务，从IT人员的角度出发，其实是另一个合法的正交易，不能算是冲账。在设计程序的时候，只要是财务类的业务，就一定要

27、考虑冲账的问题，不能偷懒，不能妄想 测试人员会遗漏。就算别人忘记了测试，如果在真实业务中发生了问题，是很麻烦的，所以 要养成良好的设计、测试的习惯。（这里不谈编码，因为设计好了自然就会写代码的） 关于冲账的实现，我知道的有两种方式：第一是正反交易的概念。也就是普通的账务交易，称之正交易。每一个正交易，都需要有一 个与之匹配的反交易，如果是按交易码来管理的话，可能会有一个标准来定义反交易的交易 码，比如说正交易码加上5000 就是相应的反交易之类的。（这里只是随便举个例子，比如说 0001 表示取款，那么5001就表示取款的反交易）因为冲账在账务处理上，具有一些共性， 比如说都是按原来的财务的会

28、计分录，只是金额为负发生账务即可，所以有可能会有一些公 共函数来调用，不过总的来说，都是小函数的概念。这种设计的缺点很显而易见，就是交易 码，代码量都要翻倍。业务人员在冲账的时候也需要稍微算算交易码，有可能会输错。好处 也是很明显的，就是程序之间互相不影响，修改维护都很容易。第二种设计思路就是大函数的概念，也就是使用一个交易来实现冲账。因为前面说过，冲账 业务具有一些普遍的共性，就基本原则来说，找到这笔正交易最初的账务，就可以了。所以 使用一个大交易来实现。至于各个业务模块冲账后，在财务处理完之后的业务冲账，那可能 就需要不断的在这个大交易中挂上各类外挂了。这种设计的缺点也很明显，就是维护起来

29、很 不方便，因为相当于把业务模块的冲账都集成到一个大交易中，在版本控制，大量测试的时 候可能会有较多冲突。好处就是不占用交易码，也可以减少很多代码量，对于很标准的冲账， 甚至不需要特别去考虑冲账的问题。（不过怕的就是不那么标准的冲账） 这两种方法各有优缺点，不知道大家的系统中，使用的哪种方式。这里我提出一个集合两者 的第三种方法，一起来参详一下： 仍然考虑以大交易为主，不过大交易按某个参数表，来决定调用业务模块中的部分程序解决 业务模块的冲账问题。如果是非常标准的冲账，就不需要刻意写冲账程序。如果是不标准的 冲账，就在参数表中按设计中自已定义好的各类标识符，使大交易可以判断出何时调用业务 模块

30、中的冲账子程序（这些冲账子程序可以随时新增，名字也可以自定义，总之是在参数表 中来定义）。至于大交易与冲账子程序中间的程序入口参数的传递，因为各个业务模块要求 都有所不同，所以可考虑使用一个大字符型字段，或是数据队列传递字符流的方式来解决。 5.9 其它暂时先想到这么多，其实还有其它的东西。比如说日终批处理，不过做到这一块 的同行们想来不是技术骨干就是业务能手，也就没必要看这份入门级的东西了。还有拆借， 贴现，不过这部分在核心系统里面占的份量很小，业务理解起来也不难，抓住一个熟悉业务 的人多问问就问出来了。还有代理业务，不过这种业务的设计也多半是主+明细的方式（比 如说代理单位的汇总信息，以及

31、相应代理业务的明细记录），麻烦的可能反而主要在数据的 交互上，也就是什么倒盘啊，信息录入啊什么的，又或者是具体的程序运行效率上，和这个 整体设计的关系倒不大。关于批处理，我做得比较多，还是再简单说两句。一般来说，会要求维护人员按各自的业务 模块，维护批处理中的相应程序。不过最后，仍然需要一个总体上能把握的人来协调调度。 批处理的程序大致上可以分为三种功能： 实现各类日终自动业务。比如说到期自动扣款（用过信用卡的朋友们应该深有体会吧），贷 款的形态转移，储蓄结息（居然现在变成一年四结，有些先进的国外系统还要天天计提，我 只能说系统的设计出发点各有不同啊），可能还会有上面提到的日终清算。当然，还包

32、括了 各类的日初业务初始化。实现账务模块数据向总账模块数据的转换，也就是更新总账模块的数据。严谨一点的系统， 在更新了总账模块的数据之后，还会用程序来检查一下总账模块的数据与业务模块中的数据 是否匹配，一致。（也就是传说中的总分核对） 生成各类报表。这部分可能主要是从总账模块中出，也可能需要综合一下业务模块中的数据。 批处理的发起，是由固定的操作人员来执行，没见过设计成按时间点自动运行的。刚才说到批处理的三项基本功能，而其实在各类功能中，程序的运行顺序还是颇有讲究，不 能随意乱放，否则可能会出现无法预知的问题。批处理的排障，也是一个比较痛苦麻烦的事情，这里真诚的建议各位维护批处理的同行在有 大模块上线前，做好心理准备，多多祈祷，实在不行还可以试试拜拜土地。（注：范文素材和资料部分来自网络，供参考。只是收取少量整理收集费用，请 预览后才下载，期待你的好评与关注）