这里记录一个解决思路

搜索栏的下拉选择框设置：

1
2
3
4
5
6
7
8
9
10
11
12

<fks-select
  v-model="searchParams.projectStatus"
  placeholder="请选择"
>
  <!-- 已完成、审批中、暂存、已驳回 -->
  <fks-option 
    v-for="item in stateOptions"
    :key="item.value"
    :label="item.label"
    :value="item.value"
  />
</fks-select>

表单列显示设置：

1
2
3
4
5
6
7
8
9
10
11
12

<fks-table-column
  prop="processState"
  label="流程状态"
  align="center"
>
  <template slot-scope="scope">
    <span v-if="scope.row.processState === '0'">已完成</span>
    <span v-else-if="scope.row.processState === '1'">审批中</span>
    <span v-else-if="scope.row.processState === '2'">暂存</span>
    <span v-else-if="scope.row.processState === '3'">已驳回</span>
  </template>
</fks-table-column>

data中的数据模型设置：

1
2
3
4
5
6
7
8
9
10
11
12
13

stateOptions:[{
  value:'0',
  label:'已完成'
},{
  value:'1',
  label:'审批中'
},{
  value:'2',
  label:'暂存'
},{
  value:'3',
  label:'已驳回'
}]

效果便是在发往后端的请求中，相关字段始终是数值型或字符型的数字，而不是文字或英文。

使用Data ID与profiles实现:

Data ID: Nacos中，可以理解为Spring Cloud应用的配置文件名。

Data ID 的名称格式是这样的：${spring.application.name}.properties

实际上，Data ID的规则中，还包含了环境逻辑，应用启动可以通过spring.profiles.active来指定具体的环境名称,那么相应客户端的配置为：${spring.application.name}-${spring.profiles.active}.yml

注释：Spring-could默认的配置为：${spring.cloud.nacos.config.prefix}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}
而上面我们写的 ：${spring.application.name}-${spring.profiles.active}.yml是因为：
${spring.cloud.nacos.config.prefix}和${spring.cloud.nacos.config.file-extension}都使用了默认值

使用Group实现

Group在Nacos中是用来对Data ID做集合管理的重要概念，我们可以把GROUP看成一个环境的集合，例如应用A归属一个GROUP-A ，应用B归属GROUP-B。对于使用GROUP没有固定要求，主要是为了们在实际使用的时候，需要根据我们的具体需求，可以是架构运维上对多环境的管理，也可以是业务上对不同模块的参数管理。

• 第一步：先在Nacos中，通过区分Group来创建两个不同环境的配置内容。
• 第二步：在alibaba-nacos-config-client应用的配置文件中，增加Group的指定配置如：spring.cloud.nacos.config.group=DEV_GROUP
• 第三步：启动应用

使用Namespace实现

NameSpace是较大粒度的隔离，它可以隔离上述说的DATA ID GROUP ，也就是说在不同的命名空间下可以存在相同的DATA ID 和 GROUP ，Namespace的常用场景之一是不同环境的配置的区分隔离，例如：开发测试环境和生产环境的资源（如配置、服务）隔离等。

使用方法：在alibaba-nacos-config-client应用的配置文件中
增加Namespace的指定配置，比如：spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a
注意 ：namespace 的配置不是使用名称，而是使用Namespace的ID。

优劣对比

利用Nacos配置管理功能中的几个不同纬度来实现多环境的配置管理。从结果上而言，不论用哪一种方式，都能够胜任需求，但是哪一种最好呢？

第一种：通过Data ID与profile实现。

• 优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。
• 缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。
• 建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划。

第二种：通过Group实现。

• 优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
• 缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
• 建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。

第三种：通过Namespace实现。

• 优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。

实际上，Nacos中并未对extension-configs和shared-configs的差别进⾏详细阐述。我们从他们的结构，看不出本质差别；除了优先级不同以外，也没有其他差别。那么，Nacos项⽬组为什么要引⼊两个类似的配置呢?我们可以从当初该功能的需求（issue）上找到其原始⽬的。

Nacos对配置的默认理念

• namespace区分环境：开发环境、测试环境、预发布环境、⽣产环境。
• group区分不同应⽤：同⼀个环境内，不同应⽤的配置，通过group来区分。

主配置是应⽤专有的配置

因此，主配置应当在dataId上要区分，同时最好还要有group的区分，因为group区分应⽤（虽然dataId上区分了，不⽤设置group也能按应⽤单独加载）。

要在各应⽤之间共享⼀个配置，请使⽤上⾯的 shared-configs

因此按该理念，shared-configs指定的配置，本来应该是不指定group的，也就是应当归⼊DEFAULT_GROUP这个公共分组。

如果要在特定范围内（⽐如某个应⽤上）覆盖某个共享dataId上的特定属性，请使⽤ extension-config

⽐如，其他应⽤的数据库url，都是⼀个固定的url，使⽤shared-configs.dataId = mysql的共享配置。但其中有⼀个应⽤demo-service是特例，需要为该应⽤配置扩展属性来覆盖。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

spring:
 application:
   name: demo-service
 cloud:
   nacos:
     config:
       server-addr: nacos-2.nacos-headless.public.svc.cluster.local:8848
       namespace: ygjpro-test2
       group: demo-group
       ......
       shared-configs[3]:
         data-id: mysql.yaml
         refresh: true
       ......
       extension-configs[3]:
         data-id: mysql.yaml
         group: demo-group
         refresh: true

关于优先级

1、上述两类配置都是数组，对同种配置，数组元素对应的下标越⼤，优先级越⾼。也就是排在后⾯的相同配置，将覆盖排在前⾯的同名配置。

• 同为扩展配置，存在如下优先级关系：extension-configs[3] > extension-configs[2] > extension-configs[1] > extension-configs[0。
• 同为共享配置，存在如下优先级关系：shared-configs[3] > shared-configs[2] > shared-configs[1] > shared-configs[0]。

2、不同种类配置之间，优先级按顺序如下：主配置 > 扩展配置(extension-configs) > 共享配置(shared-configs)。