大家好，我是不才陳某~

前面一節(jié)介紹了碼猿慢病云管理系統(tǒng)的多租戶架構(gòu)的設(shè)計(jì),，相信大家對(duì)業(yè)務(wù)也相對(duì)了解了一些,，這節(jié)就來(lái)聊一聊碼猿慢病云管理系統(tǒng)中的權(quán)限是如何設(shè)計(jì)的？

權(quán)限管控可以通俗的理解為權(quán)力限制,，即不同的人由于擁有不同權(quán)力,，他所看到的、能使用的可能不一樣,。對(duì)應(yīng)到一個(gè)應(yīng)用系統(tǒng),，其實(shí)就是一個(gè)用戶可能擁有不同的數(shù)據(jù)權(quán)限（看到的）和操作權(quán)限（使用的）。

主流的權(quán)限模型主要分為以下五種：

• ACL模型：訪問(wèn)控制列表

• DAC模型：自主訪問(wèn)控制

• MAC模型：強(qiáng)制訪問(wèn)控制

• ABAC模型：基于屬性的訪問(wèn)控制

• RBAC模型：基于角色的權(quán)限訪問(wèn)控制

目前主流的權(quán)限模型是RBAC模型,，碼猿慢病云管理系統(tǒng)則是使用RBAC模型進(jìn)行權(quán)限控制,。

關(guān)于以上5種權(quán)限模型在之前一篇文章中詳細(xì)介紹過(guò)：權(quán)限系統(tǒng)就該這么設(shè)計(jì)，yyds

RBAC 基于角色的權(quán)限訪問(wèn)控制

Role-Based Access Control,，核心在于用戶只和角色關(guān)聯(lián),，而角色代表對(duì)了權(quán)限，是一系列權(quán)限的集合,。

RBAC三要素：

1. 用戶：系統(tǒng)中所有的賬戶

2. 角色：一系列權(quán)限的集合（如：管理員,，開(kāi)發(fā)者，審計(jì)管理員等）

3. 權(quán)限：菜單,，按鈕,，數(shù)據(jù)的增刪改查等詳細(xì)權(quán)限。

在RBAC中,，權(quán)限與角色相關(guān)聯(lián),，用戶通過(guò)成為適當(dāng)角色的成員而得到這些角色的權(quán)限。

角色是為了完成各種工作而創(chuàng)造,，用戶則依據(jù)它的責(zé)任和資格來(lái)被指派相應(yīng)的角色,，用戶可以很容易地從一個(gè)角色被指派到另一個(gè)角色。

角色可依新的需求和系統(tǒng)的合并而賦予新的權(quán)限,，而權(quán)限也可根據(jù)需要而從某角色中回收,。角色與角色的關(guān)系同樣也存在繼承關(guān)系防止越權(quán)。

優(yōu)點(diǎn)：便于角色劃分,，更靈活的授權(quán)管理,；最小顆粒度授權(quán)；

在碼猿慢病云管理系統(tǒng)（醫(yī)療系統(tǒng)）的用戶、角色,、權(quán)限代表什么呢,？

1. 用戶

這里的用戶和其他系統(tǒng)并無(wú)區(qū)別，則是能登錄系統(tǒng)的用戶,，對(duì)應(yīng)的表為：codepae/sys_user,，字段屬性如下：

其中比較重要的字段：

1. username：用戶登錄系統(tǒng)的賬號(hào)，醫(yī)療系統(tǒng)中則是HIS系統(tǒng)中的工號(hào),，(username,hos_id,del_flag)組成唯一索引,，同一家醫(yī)院這個(gè)賬號(hào)必須是唯一
2. hos_id：醫(yī)院的ID，多租戶架構(gòu)模式下區(qū)分租戶的字段
3. dept_id：科室ID/病區(qū)ID,，醫(yī)院中的醫(yī)生,、護(hù)士是按照科室/病區(qū)管理患者的，因此在入職時(shí)就會(huì)分配到對(duì)應(yīng)的科室/病區(qū),，比如女人的婦科病,，去醫(yī)院看病掛的肯定是婦科，這個(gè)婦科門診則是有對(duì)應(yīng)的醫(yī)生坐診,，不可能找個(gè)骨科的醫(yī)生去看婦科的毛病

為什么要有科室,、病區(qū)這兩個(gè)概念？

科室則是平常我們醫(yī)院掛號(hào)經(jīng)?？吹降目剖?，比如婦科、骨科,、內(nèi)分泌科,、心內(nèi)科、心腦血管科等

病區(qū)這個(gè)概念是針對(duì)住院來(lái)說(shuō),，住過(guò)院的應(yīng)該都知道護(hù)士照顧病人是通過(guò)病區(qū)->病房->床位號(hào)定位病人,，比如二十病區(qū)->302房間->10號(hào)床

醫(yī)院為了病房能夠更好的管理，節(jié)省醫(yī)護(hù)的資源,，一個(gè)病區(qū)中包含多個(gè)科室的患者,，比如新生兒科、產(chǎn)科,、兒科這三個(gè)科室你會(huì)看到里面的住院患者都是住在同一個(gè)病區(qū),，同一批護(hù)士管理，比如十病區(qū),。

這樣應(yīng)該就能理解了,，大部分的HIS系統(tǒng)中,，醫(yī)生是劃分到科室管理,，比如婦科,，骨科，畢竟術(shù)業(yè)有專攻,，護(hù)士是按照病區(qū)劃分管理,，因?yàn)樽o(hù)士本質(zhì)上是照顧病人，打打針等一些工作,，專一性不是那么高,；因此在sys_user用戶表中的dept_id既能表示科室也能表示病區(qū)了。

PS：一些比較落后的小醫(yī)院,，HIS系統(tǒng)比較老舊,，醫(yī)生、護(hù)士還是按照科室管理

2. 角色

在醫(yī)院中的主要角色則是：醫(yī)生和護(hù)士,，這個(gè)想必大家都能理解

碼猿慢病云管理系統(tǒng)中內(nèi)置了七個(gè)角色,，已經(jīng)完全夠用了，如下：

• 管理員：這個(gè)是每個(gè)醫(yī)院的系統(tǒng)管理員,，在添加醫(yī)院的時(shí)候會(huì)指定一個(gè)管理員
• 系統(tǒng)管理員：這個(gè)是整個(gè)系統(tǒng)的管理員,，擁有最高權(quán)限，可以看到所有醫(yī)院的數(shù)據(jù)
• 醫(yī)生：醫(yī)生的角色
• 護(hù)士：護(hù)士的角色

對(duì)應(yīng)數(shù)據(jù)庫(kù)：codeape/sys_role,，如下：

和用戶通過(guò)另外一張表存儲(chǔ)關(guān)聯(lián)關(guān)系：codeape/sys_user_role

碼猿慢病云管理系統(tǒng)中醫(yī)生和護(hù)士這兩個(gè)角色的最大區(qū)別：護(hù)士需要手持PDA（數(shù)據(jù)采集設(shè)備）采集數(shù)據(jù)(血糖、尿酸,、血酮),，添加數(shù)據(jù)等操作，醫(yī)生則是每天查看患者的數(shù)據(jù)為治療提供輔助

3. 權(quán)限

碼猿慢病云管理系統(tǒng)中的權(quán)限有如下三類：

1. 菜單的權(quán)限：客戶端菜單的權(quán)限
2. 按鈕/接口的權(quán)限：客戶端按鈕/接口的權(quán)限,，比如添加患者這個(gè)
3. 科室/病區(qū)的權(quán)限：

1. 菜單的權(quán)限

控制客戶端的菜單顯示,，如下：

目前有這幾個(gè)根菜單+子菜單。

2. 按鈕權(quán)限

客戶端按鈕的權(quán)限,，比如新增,、刪除、編輯按鈕的權(quán)限,，比如住院患者的4個(gè)按鈕,，如下：

每個(gè)按鈕都有一個(gè)權(quán)限標(biāo)識(shí)編碼，比如inhos_patinfohot_get,，客戶端只需要判斷當(dāng)前登錄用戶的權(quán)限樹(shù)中是否存在這個(gè)權(quán)限,，有則顯示，沒(méi)有則不顯示

3. 接口權(quán)限

客戶端的接口權(quán)限和按鈕權(quán)限共用,，比如查詢住院患者這個(gè)權(quán)限對(duì)應(yīng)的標(biāo)識(shí)也是：inhos_patinfohot_get

那么這個(gè)接口權(quán)限如何控制,？碼猿慢病云管理系統(tǒng)中是將接口權(quán)限的鑒權(quán)下沉到各個(gè)微服務(wù),，交給開(kāi)發(fā)者在開(kāi)發(fā)接口時(shí)通過(guò)@PreAuthorize注解控制權(quán)限，比如查詢住院患者列表的這個(gè)接口,，如下：

 //com.code.ape.codeape.inhos.controller.PatInfoHotController#getPatInfoHotPage
 @Operation(summary = "分頁(yè)查詢?cè)谠夯颊?, description = "分頁(yè)查詢?cè)谠夯颊?)
    @GetMapping("/page" )
 @InjectAuth
    @PreAuthorize("@pms.hasPermission('inhos_patinfohot_get')" )
    public R<Page<PatInfoVO>> getPatInfoHotPage(Page<PatInfoVO> page, PatInfoDTO dto) {
        return R.ok(patInfoHotService.listPage(page,dto));
    }

@PreAuthorize這個(gè)注解是Spring Security內(nèi)置的鑒權(quán)接口,，其中的value這個(gè)屬性支持SPEL表達(dá)式，真實(shí)的實(shí)現(xiàn)代碼如下：

/**
 * @author 公眾號(hào)：碼猿技術(shù)專欄   版權(quán)：不才陳某所署,，侵權(quán)必究
 * {@link com.code.ape.codeape.common.security.component.PermissionService}
 */
public class PermissionService {
 /**
  * 判斷接口是否有任意xxx,，xxx權(quán)限
  * @param permissions 權(quán)限
  * @return {boolean}
  */
 public boolean hasPermission(String... permissions) {
  if (ArrayUtil.isEmpty(permissions)) {
   return false;
  }
        //代碼(1)
  Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
  if (authentication == null) {
   return false;
  }
        //代碼(2)
  Collection<? extends GrantedAuthority> authorities = authentication.getAuthorities();
  ////代碼(3)
        return authorities.stream()
   .map(GrantedAuthority::getAuthority)
   .filter(StringUtils::hasText)
   .anyMatch(x -> PatternMatchUtils.simpleMatch(permissions, x));
 }
}

邏輯其實(shí)很簡(jiǎn)單，上述代碼三個(gè)部分：

• 代碼(1) ：從Spring Security 上下文中獲取當(dāng)前用戶登錄的身份信息Authentication,，其中就包括權(quán)限
• 代碼(2) ：從用戶身份信息Authentication中獲取用戶的權(quán)限樹(shù)
• 代碼(3) ：將當(dāng)前登錄用戶的權(quán)限和@PreAuthorize傳入的權(quán)限比較,，判斷是否鑒權(quán)通過(guò)

4. 科室/病區(qū)權(quán)限

這個(gè)權(quán)限則是比較特殊了，先描述一下場(chǎng)景：

在醫(yī)療系統(tǒng)中,，醫(yī)生/護(hù)士是無(wú)權(quán)限查看全部科室的數(shù)據(jù)的,，只能查看自己負(fù)責(zé)科室/病區(qū)的數(shù)據(jù)，這樣是為了避免醫(yī)療事故,；你想想如果有個(gè)心懷不軌的醫(yī)生,，隨意更改其他科室/病區(qū)患者的數(shù)據(jù)，導(dǎo)致醫(yī)生誤判病情,，這樣的責(zé)任誰(shuí)來(lái)承擔(dān),？

所以醫(yī)療系統(tǒng)中都需要控制醫(yī)護(hù)科室/病區(qū)這個(gè)權(quán)限，這樣才能保證不發(fā)生不必要的醫(yī)療事故,。

碼猿慢病云管理系統(tǒng)中的科室/病區(qū)權(quán)限如何控制的呢,？

在新增醫(yī)護(hù)的時(shí)候有個(gè)科室權(quán)限的多選器，如下圖：

這樣就能輕松設(shè)置醫(yī)護(hù)的科室/病區(qū)權(quán)限了,，這部分對(duì)應(yīng)關(guān)系是持久化在codeape/sys_user_dept這張表中,，如下：

那么此時(shí)當(dāng)前醫(yī)護(hù)的科室/病區(qū)權(quán)限如何計(jì)算呢？

先給答案,，分為兩種情況,；

第一種：WEB端/PAD端

先說(shuō)第一種：在WEB端/PAD端，醫(yī)護(hù)的權(quán)限=醫(yī)護(hù)所在的科室+醫(yī)護(hù)的科室權(quán)限+關(guān)聯(lián)科室

什么意思,？比如白鹿這個(gè)護(hù)士,，如下圖：

所屬科室為內(nèi)分泌科，科室權(quán)限為神經(jīng)內(nèi)科+內(nèi)分泌科+心內(nèi)科,，那么前面兩層的權(quán)限則是神經(jīng)內(nèi)科+內(nèi)分泌科+心內(nèi)科（注意去重）

那么關(guān)聯(lián)科室什么意思,？比如神經(jīng)內(nèi)科下面有個(gè)神經(jīng)內(nèi)科病區(qū)，但是醫(yī)護(hù)的科室在入職時(shí)都設(shè)置在了神經(jīng)內(nèi)科,，那么他們?nèi)绾文芸吹缴窠?jīng)內(nèi)科病區(qū)的數(shù)據(jù)呢,？

一種方案可以在科室權(quán)限那一欄再加上神經(jīng)內(nèi)科病區(qū)，這種當(dāng)然可行,，但是你要為每個(gè)醫(yī)護(hù)都設(shè)置一遍,。

第二種方案：可以將神經(jīng)內(nèi)科和神經(jīng)內(nèi)科病區(qū)關(guān)聯(lián)起來(lái),，這樣只要有神經(jīng)內(nèi)科這個(gè)權(quán)限，那么就必然有神經(jīng)內(nèi)科病區(qū)這個(gè)權(quán)限,，這個(gè)在碼猿慢病云管理系統(tǒng)中也有設(shè)置關(guān)聯(lián)關(guān)系,，如下圖：

在添加科室的時(shí)候可以選擇根節(jié)點(diǎn)科室。

對(duì)應(yīng)的關(guān)系持久化在codeape/sys_dept_relation中,，結(jié)構(gòu)如下：

科室/病區(qū)權(quán)限在用戶登錄時(shí)就會(huì)查詢出來(lái)放到SecurityContext上下文中,，具體的方法如下圖：

那在醫(yī)護(hù)查詢數(shù)據(jù)如何去根據(jù)這個(gè)科室/病區(qū)權(quán)限過(guò)濾呢,？

在請(qǐng)求DTO中有個(gè)基礎(chǔ)實(shí)體類com.code.ape.codeape.common.core.entity.BaseParam,，如下：

@Data
public class BaseParam {

   /**
    * 醫(yī)院Id
    */
   private Long hosId;

   /**
    * 用戶ID
    */
   private Long userId;

   /**
    * 醫(yī)護(hù)的科室權(quán)限
    */
   private List<Long> dataAuth;

   /**
    * 請(qǐng)求來(lái)源客戶端ID
    */
   private String clientId;

   /**
    * 設(shè)備的SN號(hào)
    */
   private String sn;
}

這個(gè)類中的所有屬性都會(huì)自動(dòng)注入，只需要在controller方法中標(biāo)注一個(gè)注解：@InjectAuth,，如何做到的呢,？

@InjectAuth這個(gè)注解是通過(guò)AOP方式自動(dòng)注入?yún)?shù)，代碼如下：

@Slf4j
@RequiredArgsConstructor
@Aspect
public class CodeapeInjectAuthAspect implements Ordered {


 @SneakyThrows
 @Around("@annotation(injectAuth) &&" +
   "(@annotation(org.springframework.web.bind.annotation.PostMapping)||" +
   "@annotation(org.springframework.web.bind.annotation.GetMapping)||" +
   "@annotation(org.springframework.web.bind.annotation.DeleteMapping)||" +
   "@annotation(org.springframework.web.bind.annotation.PutMapping)||" +
   "@annotation(org.springframework.web.bind.annotation.RequestMapping))")
 public Object around(ProceedingJoinPoint joinPoint, InjectAuth injectAuth) {
  if (injectAuth.enable()){
   CodeapeUser codeapeUser = Objects.requireNonNull(SecurityUtils.getUser());
   Object[] args = joinPoint.getArgs();
   for (int i = 0; i < args.length; i++) {
    if (!(args[i] instanceof BaseParam)) {
     continue;
    }
    BaseParam baseParam = (BaseParam) args[i];

    /**
     * 1. web端：權(quán)限就是當(dāng)前登錄用戶的權(quán)限
     * 2. pda端,，權(quán)限則是設(shè)備的權(quán)限+當(dāng)前登錄用戶的權(quán)限
     * 這里的權(quán)限取值是token中的deptAuths,，這個(gè)在登錄的時(shí)候就查詢出來(lái)，緩存在redis中,，所以這里直接用就可以
     */
    //醫(yī)院管理員+系統(tǒng)管理員不賦予權(quán)限
    boolean flag= ArrayUtil.contains(codeapeUser.getRoleCodes(),SecurityConstants.SYSTEM_ADMIN_CODE)
  ||ArrayUtil.contains(codeapeUser.getRoleCodes(),SecurityConstants.HOS_ADMIN_CODE);
    baseParam.setDataAuth(flag?null:Arrays.asList(codeapeUser.getDeptAuths()));
    baseParam.setHosId(codeapeUser.getHosId());
    baseParam.setUserId(codeapeUser.getId());
    baseParam.setClientId(codeapeUser.getClientId());
    baseParam.setSn(codeapeUser.getSn());
   }
  }
  return joinPoint.proceed();
 }


 @Override
 public int getOrder() {
  return Ordered.HIGHEST_PRECEDENCE + 4;
 }
}

直接取的是CodeapeUser中的deptAuths,，CodeapeUser則是SecurityContext上下文的用戶身份信息

這樣則能夠取到用戶的科室/病區(qū)權(quán)限，然后則能在SQL中根據(jù)這個(gè)dataAuth屬性去過(guò)濾數(shù)據(jù)了,，比如分頁(yè)查詢住院患者的接口,，controller方法如下：

com.code.ape.codeape.inhos.controller.PatInfoHotController#getPatInfoHotPage

SQL如下：

com.code.ape.codeape.inhos.mapper.PatInfoHotMapper#selectPatInfoPage

這部分的SQL片段則是根據(jù)住院患者的科室去過(guò)濾。

第二種PDA端

這里的PDA指的是護(hù)士的手持設(shè)備,，這個(gè)設(shè)備和智能手機(jī)一樣,，根據(jù)自己賬號(hào)登錄上去，給大家大致畫(huà)一下PDA上都有哪些內(nèi)容,，如下圖：

其實(shí)就和APP是一樣的,，里面可以看到大致四塊內(nèi)容（當(dāng)然還有其他)：

1. 患者管理：這個(gè)是顯示所有的住院患者，護(hù)士可以選擇對(duì)應(yīng)的患者進(jìn)行數(shù)據(jù)采集,，這樣采集的數(shù)據(jù)才能和患者自定綁定

2. 檢測(cè)任務(wù)：這個(gè)則是醫(yī)生下的醫(yī)囑任務(wù),，按照時(shí)間段顯示，比如醫(yī)生下的三餐前后測(cè)血糖這個(gè)醫(yī)囑任務(wù),，則經(jīng)過(guò)護(hù)士拆分后,，則變成了6個(gè)子任務(wù)：空腹測(cè)血糖、早餐后測(cè)血糖,、午餐前測(cè)血糖,、午餐后測(cè)血糖、晚餐前測(cè)血糖,、晚餐后測(cè)血糖,。那么在每個(gè)時(shí)間段顯示要測(cè)血糖的患者床位即可,，護(hù)士選擇對(duì)應(yīng)的床位則可以測(cè)血糖

3. 檢測(cè)記錄：這里是展示所有患者測(cè)量的血糖數(shù)據(jù)，按照時(shí)間段表格形式的展示

4. 質(zhì)控：這個(gè)則是設(shè)備的質(zhì)控,，護(hù)士每天要定時(shí)對(duì)設(shè)備進(jìn)行質(zhì)控(質(zhì)量檢測(cè)),，查看這臺(tái)設(shè)備測(cè)量是否準(zhǔn)確

那么問(wèn)題來(lái)了，PDA上需要顯示的數(shù)據(jù)是整個(gè)醫(yī)院的數(shù)據(jù)嗎,？顯然不可能,，也是需要根據(jù)護(hù)士科室/病區(qū)權(quán)限過(guò)濾，可以看到上方有一個(gè)科室的篩選項(xiàng),，默認(rèn)是所有科室,，則是當(dāng)前登錄用戶的所有科室權(quán)限

那么PDA端的醫(yī)護(hù)權(quán)限和WEB端一樣嗎？

當(dāng)然不是,，因?yàn)樵O(shè)備存在以下兩種網(wǎng)絡(luò)情況：

1. 在線：連上wifi或者SIM卡,，這樣能夠時(shí)刻保持網(wǎng)絡(luò)暢通的情況下，屬于在線狀態(tài),，拉數(shù)據(jù)/上傳數(shù)據(jù)直接訪問(wèn)服務(wù)端即可
2. 離線：有些醫(yī)院沒(méi)有內(nèi)網(wǎng)的wifi或者SIM卡,，只能連有線網(wǎng)絡(luò)，一旦設(shè)備拔掉網(wǎng)線去病房檢測(cè),，則是離線的狀態(tài)

離線情況下就需要設(shè)備本地做緩存了,，那么這個(gè)緩存的數(shù)據(jù)到底拉哪些數(shù)據(jù)？不可能將整個(gè)醫(yī)院的數(shù)據(jù)都拉下來(lái),，設(shè)備的內(nèi)存是有限的,。這個(gè)時(shí)候就需要用到設(shè)備的權(quán)限了，在添加設(shè)備的時(shí)候有兩個(gè)的選項(xiàng),，如下：

科室和關(guān)聯(lián)科室這兩個(gè)選項(xiàng),，一般一臺(tái)設(shè)備只供一個(gè)病區(qū)使用，此時(shí)將科室選項(xiàng)選擇對(duì)應(yīng)的病區(qū)即可,，那么特殊情況下,，比如一病區(qū)和二病區(qū)共用一臺(tái)設(shè)備，此時(shí)就需要用到關(guān)聯(lián)科室了,。

此時(shí)應(yīng)該明白了設(shè)備的權(quán)限=科室+關(guān)聯(lián)科室

只要設(shè)備連上網(wǎng)絡(luò),，在用戶不登錄的情況下，調(diào)用接口獲取數(shù)據(jù)的時(shí)候就應(yīng)該獲取的是設(shè)備權(quán)限的數(shù)據(jù),。

那登錄該臺(tái)設(shè)備的用戶權(quán)限呢,？應(yīng)該怎么取值呢？很簡(jiǎn)單,，分為兩種情況：

1. 用戶的權(quán)限和設(shè)備的權(quán)限取并集
2. 用戶的權(quán)限和設(shè)備的權(quán)限取交集

按照正常的邏輯是應(yīng)該是第二種情況取交集,，因?yàn)槟阕o(hù)士沒(méi)有這個(gè)權(quán)限就不應(yīng)該看到該科室/病區(qū)的數(shù)據(jù)，但是實(shí)際情況是很多醫(yī)院的護(hù)士都是輪轉(zhuǎn)的,，比如這個(gè)月到一病區(qū),，下個(gè)月到二病區(qū),，他們的科室/病區(qū)權(quán)限的維護(hù)并不是很及時(shí)，主要是信息科的人員太懶了,，這樣的話就會(huì)導(dǎo)致如果按照第二種情況取交集,，那么這個(gè)護(hù)士登錄該臺(tái)設(shè)備就看不到自己所管的科室/病區(qū)的數(shù)據(jù)了。所以在碼猿慢病云管理系統(tǒng)中是采用的第一種方案,。

相關(guān)代碼在com.code.ape.codeape.common.security.service.CodeapePDAUserDetailsServiceImpl#getUserDetails,，如下圖：

總結(jié)

這節(jié)內(nèi)容介紹了RBAC權(quán)限模型以及碼猿慢病云管理系統(tǒng)中權(quán)限是如何設(shè)計(jì)的，最重要的是科室/病區(qū)權(quán)限的設(shè)計(jì),，大家一定要理解其中的邏輯,，幾乎所有的醫(yī)療系統(tǒng)都是按照這個(gè)邏輯處理的。

本節(jié)內(nèi)容摘錄了部分代碼,，關(guān)于代碼的詳細(xì)介紹會(huì)在后面文章中介紹,，現(xiàn)在先了解一下,。

最后說(shuō)一句（別白嫖,，求關(guān)注）

陳某每一篇文章都是精心輸出，如果這篇文章對(duì)你有所幫助,，或者有所啟發(fā)的話,，幫忙點(diǎn)贊、在看,、轉(zhuǎn)發(fā),、收藏，你的支持就是我堅(jiān)持下去的最大動(dòng)力,！