BON 是什么

一句话

BON（Better Object Notation）是一门编译期执行的、声明式的数据转换语言，是 JSON 的超集。

解决了什么问题

JSON 的痛点

JSON 是最流行的数据交换格式，但它有几个固有缺陷：

问题	示例
无法复用	同样的配置块要写 5 遍，改一处要改 5 处
无法继承	Kubernetes Deployment 的基础配置每个环境都要复制粘贴
无法计算	"total": price * quantity 写不了
没有注释	JSON 标准不允许注释，配置一多就看不懂
没有模板	"image": "nginx:" + tag 拼接不了

YAML 解决了注释问题，但没解决复用和计算。TOML 也一样。配置语言一直在"格式"上做文章，没有人从"表达能力"入手。

BON 的回答

BON 不是另一种格式，而是一种编译到 JSON 的 DSL：

• 写的时候：可以用模板复用、可以用类继承、可以写表达式、可以 import
• 用的时候：输出纯 JSON，宿主程序零改动

# BON 源码（写的时候像代码）
cpu-{"cpu": "250m", "memory": "256Mi"}

class WebService {
    "replicas": 1,
    "resources": {cpu}
}

{
    "dev": WebService { "name": "api-dev" },
    "prod": WebService { "name": "api-prod", "replicas": 3 }
}

// 输出的 JSON（用的时候是数据）
{
    "dev": { "name": "api-dev", "replicas": 1, "resources": {"cpu":"250m","memory":"256Mi"} },
    "prod": { "name": "api-prod", "replicas": 3, "resources": {"cpu":"250m","memory":"256Mi"} }
}

设计哲学

1. 完全兼容 JSON

所有合法的 JSON 文件都是合法的 BON 文件。BON 不引入新格式，只在 JSON 之上增加语法糖。

2. 编译期求值，零运行时

BON 的所有逻辑（模板展开、类实例化、方法调用、标准库函数）都在解析时完成。宿主程序拿到的永远是纯净的 JSON，不需要内置 BON 运行时。

BON 源码 → [词法分析] → [语法分析] → [导入解析] → [模板展开] → [实例化与常量折叠] → 纯 JSON

3. 确定性

BON 是图灵不完备的——没有循环、没有随机数、没有系统时间。相同的源码在任何环境、任何时间解析，输出结果完全一致。

4. 比模板更强，比语言更弱

能力	JSON	YAML	BON	Python/TS
注释	✗	✓	✓	✓
模板复用	✗	✗	✓	✓
类继承	✗	✗	✓	✓
表达式计算	✗	✗	✓	✓
标准库	✗	✗	✓	✓
import	✗	✗	✓	✓
循环/条件	✗	✗	✗	✓
类型系统	✗	✗	✗	✓
运行时依赖	无	无	无	需要

BON 卡在配置语言和编程语言之间：比 JSON/YAML 强，但不会滑向编程语言。

适用场景

• Kubernetes 配置：多个环境的 Deployment、Service 共享基础模板
• 微服务配置：服务间共享端口、资源限制等公共配置
• 构建配置：多包项目的共享构建参数
• 数据生成：批量生成结构化的 JSON 数据
• 任何"用 JSON 但觉得不够用"的场景

不适用场景

• 需要运行时逻辑（条件分支、循环）→ 用 Python/TS
• 需要类型检查 → 用 TypeScript
• 需要完整编程能力 → 用任意编程语言
• 简单的键值配置 → JSON 就够了