为什么选择 ASUN？
ASUN 不是为了替代所有 JSON，而是为了在“重复结构数据”这类场景里给出更好的表达方式。
1. Token 更省
JSON 会在数组中的每个对象里反复重复字段名。ASUN 把 schema 提到前面，只写一次。
json
{
"users": [
{ "id": 1, "name": "Alice", "active": true },
{ "id": 2, "name": "Bob", "active": false }
]
}asun
[{id@int, name@str, active@bool}]:
(1, Alice, true),
(2, Bob, false)对列表型负载，这通常意味着明显更低的 token 与更小的文本体积。
2. 解析模型更有优势
ASUN 的优势主要来自模型本身，而不是某一种实现技巧：
- schema 只解析一次
- 每一行只需要读值
- 解码器可以按字段顺序工作
- 不需要为每个对象反复匹配字段名
但具体倍数取决于实现
不同语言的实际表现会受到这些因素影响：
- 语言与运行时
- 实现成熟度
- 文本还是二进制
- 平面结构还是深层嵌套
- 分配策略
- benchmark 方法
所以网站不再把性能写成“所有语言统一的一个倍数”。
| 实现类型 | 常见表现 |
|---|---|
| 原生 / 系统语言 | 通常收益最大 |
| 托管运行时 | 在真实负载里也常常很强 |
| 动态运行时 | 在重复结构数据上依然可能有明显收益 |
| 较新的实现 | 可能仍在调优中 |
如果你要看实现级说明，请直接看 性能概览 和 benchmark notes。
3. 对 LLM 更友好
ASUN 的输出更接近“有表头的行数据”，而不是一堆重复 key 的 JSON 对象。
- 大多数字符串无需引号
- 结构更线性
- schema 可以在一次对话里复用
这通常意味着更少的格式错误和更低的 token 成本。
4. 对人也更友好
asun
[{id@int, name@str, role@str, score@float}]:
(1, Alice, admin, 9.5),
(2, Bob, viewer, 7.2),
(3, Carol, editor, 8.8)当数据天然是“表格型”时，ASUN 通常比 JSON 更容易扫读。
什么时候继续用 JSON
下面这些场景不需要强行换成 ASUN：
- 结构完全动态、字段变化很大
- 需要对接外部 JSON API
- 载荷很小，重复 key 根本不是问题
ASUN 最适合的是重复结构、同构数组、列表型数据交换。