数据类型与格式：字符串、数字、布尔、数组、对象

说实话，刚接触 DaVinci Config 那会儿，我总觉得数据类型这玩意儿没啥好学的。不就是字符串、数字这些嘛，谁不会啊？结果呢？第一次做项目配置，就因为把布尔值写成了字符串 "false"，导致整个功能模块死活不生效。嗯，从那以后，我再也不敢小看这些基础类型了。

今天咱们就好好聊聊 DaVinci Config 里的数据类型，以及 JSON 和 YAML 这两种格式该怎么选。我个人习惯是把这部分内容当作配置工程的「地基」——地基没打好，上面盖多高的楼都得塌。

一、五大基础数据类型

DaVinci Config 支持的数据类型，说白了就五种：字符串、数字、布尔、数组、对象。咱们一个一个来看。

1. 字符串（String）

字符串是最常用的类型。配置项的名字、描述、路径，基本都是字符串。

关键点：字符串必须用引号包起来。单引号双引号都行，但建议统一风格。

# YAML 示例
app_name: "MyDaVinciApp"
version: '1.0.0'
description: 这是一个示例配置  # 不加引号也可以，但建议加上

我在项目中遇到过一个问题：某个配置项的字符串值里包含了冒号，结果 YAML 解析直接报错。后来我养成了一个习惯——所有字符串都加引号，省心。

小技巧：如果字符串里包含特殊字符（如冒号、#、!），一定要加引号。否则 YAML 解析器会误解。

2. 数字（Number）

数字类型包括整数和浮点数。DaVinci Config 里，数字不需要加引号。

# YAML 示例
max_connections: 100
timeout_seconds: 30.5
retry_count: 3

这里有个坑——我曾经把端口号写成了 "8080"（带引号），结果系统把它当字符串处理了，导致网络连接失败。排查了半天才发现是类型问题。

注意：数字不要加引号！加了引号就变成字符串了，运算和比较都会出问题。

3. 布尔（Boolean）

布尔值只有两个：true 和 false。在 YAML 里，还可以用 yes/no、on/off 来表示，但我建议统一用 true/false。

# YAML 示例
enable_logging: true
debug_mode: false
# 下面这种写法虽然可以，但不推荐
use_cache: yes
show_warnings: no

为什么我建议统一用 true/false？因为我在项目里见过有人混用 yes/true/on，结果新同事接手时一脸懵，还得去查文档确认每个值的含义。统一风格，减少认知负担。

最佳实践：布尔值统一使用 true/false，不要用 yes/no 或 on/off。

4. 数组（Array）

数组就是一组值的集合。在 YAML 里有两种写法：列表形式和行内形式。

# 列表形式（推荐）
allowed_origins:
  - "http://localhost:3000"
  - "https://example.com"
  - "https://api.example.com"

# 行内形式
allowed_origins: ["http://localhost:3000", "https://example.com", "https://api.example.com"]

我个人习惯用列表形式，尤其是数组元素比较多的时候。行内形式适合元素少、一眼能看完的场景。

5. 对象（Object）

对象就是键值对的集合。在 DaVinci Config 里，对象用来组织复杂的配置结构。

# YAML 示例
database:
  host: "localhost"
  port: 5432
  username: "admin"
  password: "secret123"
  pool:
    min: 5
    max: 20

对象可以嵌套，就像上面的 pool 一样。但要注意，嵌套层级不要太深，否则配置会变得很难维护。我见过有人嵌套了七八层，改一个配置得翻半天。

建议：对象嵌套不要超过 3 层。超过 3 层，就该考虑拆分配置了。

二、JSON vs YAML：怎么选？

这个问题我经常被问到。说实话，没有绝对的好坏，关键看场景。

对比维度 JSON YAML
可读性 一般，括号多 优秀，缩进清晰
编写效率 较低，需要写括号和逗号 较高，简洁明了
注释支持 不支持 支持（# 注释）
解析速度 快 稍慢
工具兼容性 几乎所有语言都支持 大部分语言支持
错误容忍度 高，格式错误容易发现 低，缩进错误很难排查

我个人是这样选的：

  • 手写配置：用 YAML。注释方便，写起来快，可读性好。
  • 程序生成配置：用 JSON。解析快，兼容性好，不容易出错。
  • 团队协作：用 YAML。注释可以写清楚每个配置项的用途，新人上手快。

我的建议：DaVinci Config 配置，优先用 YAML。原因很简单——你写配置的时候，可读性和注释比解析速度重要得多。

三、实战中的数据类型陷阱

讲几个我踩过的坑，你们引以为戒。

陷阱一：数字和字符串混淆

# 错误示例
timeout: "30"  # 这是字符串，不是数字

# 正确示例
timeout: 30    # 这才是数字

我曾经在配置里把超时时间写成了字符串，结果系统一直报类型错误。排查了半天才发现是引号的问题。

陷阱二：布尔值的多种写法

# 这些写法在 YAML 里都是 true
enabled: true
enabled: yes
enabled: on
enabled: True
enabled: TRUE

# 但这些写法可能不是你想要的结果
enabled: "true"   # 这是字符串，不是布尔值
enabled: 'yes'    # 这也是字符串

嗯，这里要注意——带引号的 true 是字符串，不是布尔值。很多新手在这里翻车。

陷阱三：数组元素的类型一致性

# 不推荐：混合类型
mixed_list:
  - "hello"
  - 123
  - true

# 推荐：统一类型
string_list:
  - "hello"
  - "world"
  - "123"

虽然 DaVinci Config 允许数组里混用不同类型，但我建议保持类型一致。否则遍历的时候还得做类型判断，徒增复杂度。

重要提醒：YAML 对缩进非常敏感。缩进不一致，配置就解析失败。我建议用 2 个空格作为缩进单位，不要用 Tab。

四、格式选择的决策流程

如果你还是不知道怎么选，可以参考这个流程：

  1. 配置是给人看的还是给机器看的？
    • 给人看 → YAML
    • 给机器看 → JSON
  2. 配置需要注释吗？
    • 需要 → YAML
    • 不需要 → JSON
  3. 配置会被频繁修改吗？
    • 会 → YAML（修改方便）
    • 不会 → JSON（稳定可靠）
  4. 团队里有人不熟悉 YAML 吗？
    • 有 → JSON（学习成本低）
    • 没有 → YAML（效率更高）

说白了，大部分场景下 YAML 都是更好的选择。但如果你需要和外部系统对接，或者配置需要程序频繁读写，JSON 会更稳妥。

终极建议：不管选哪种格式，一致性比「最优选择」更重要。团队统一用一种格式，比换来换去强一百倍。

好了，数据类型和格式选择就聊到这儿。下一章咱们聊聊配置文件的组织结构和模块化设计——这部分内容，说实话，才是真正拉开配置效率差距的地方。

← 上一章 📖 返回目录 下一章 →