今日三荐：浮点解析、CBOR 解码与正则引擎

1. fast_float：每一个十进制数都舍入到最近的那一个

为什么今天看

最值得拆的机制

• 一个头文件，两个函数。 fast_float::from_chars(first, last, value) 把一段字符解析成 float 或 double，返回的 from_chars_result 里，ptr 指向解析停下的位置，ec 是错误码。7
• 正确舍入是硬约束。 文档的原话是：结果是最近的浮点值，恰好落在两个浮点数正中间时按偶数尾数舍入（round to nearest even），也就是 IEEE 标准下的精确解析。7
• 快路径拿不准，就退回精确路径。 主算法来自 Daniel Lemire 的《Number Parsing at a Gigabyte per Second》：先猜一个近似值再验证，验证不过才用大整数精确算。后续那篇《Fast Number Parsing Without Fallback》又把多数输入的回退省掉了。89
• 它不抛异常、不分配内存、与 locale 无关。 这三条是它和 strtod 的分界：strtod 跟着进程的 locale 走，还会写 errno。7
• 它已经进了不少你熟悉的东西。 Chromium、WebKit、Blender、DuckDB、Apache Arrow、ClickHouse 都在用这份实现，算法本身也被收进 LLVM 的标准库。7

复现难度：低

最小上手路径

git clone --depth 1 https://github.com/fastfloat/fast_float.git

// demo.cpp
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include "fast_float/fast_float.h"

int main() {
  const char* s = "3.141592653589793";
  double a = 0;
  auto r = fast_float::from_chars(s, s + strlen(s), a);
  printf("fast_float: %.17g  (停在第 %zu 个字符, ec=%d)\n", a, (size_t)(r.ptr - s), (int)r.ec);
  printf("strtod    : %.17g\n", strtod(s, nullptr));
}

g++ -std=c++17 -I fast_float/include -O2 demo.cpp -o demo && ./demo

fast_float: 3.1415926535897931  (停在第 17 个字符, ec=0)
strtod    : 3.1415926535897931

今晚练习

1. 把 "0.1" 分别喂给 from_chars 和 strtod，用 %.20g 打印。本机两边都是 0.10000000000000000555，也就是同一个二进制数。7
2. 生成一百万个「整数部分加六位小数」的随机数，一边用 from_chars、一边用 strtod 循环解析并计时。本机（g++ 14、-O2）跑出来是 9 毫秒对 61 毫秒。
3. 输入 1e9999 和 1e-9999，检查 ec 是不是 std::errc::result_out_of_range，值是不是变成了正无穷和零。7

版本动作与限制

2. fxamacker/cbor：把解码器的上限写进默认值

为什么今天看

最值得拆的机制

• CBOR 是 JSON 的二进制对应物。 它是 IETF 标准（STD 94，即 RFC 8949），这个库同时支持 RFC 8742 的 CBOR Sequence。12
• 默认上限是它对抗恶意输入的第一道墙。 解码器的 MaxNestedLevels 默认 32、MaxArrayElements 默认 131072、MaxMapPairs 各有默认值，三者都可以用 DecOptions 调。12 本机拿一个声明长度是 4294967295 的数组去解，报的是 exceeded max number of elements 131072 for CBOR array——解码器读完头部就拒绝，不会先按长度分配。
• 重复的 map 键会被检出。 12
• README 直接点了一个反面教材。 它写：有些编解码器在解码坏数据时会崩溃或者吃掉过多资源，并拿 Go 标准库 encoding/gob 举例——181 字节的数据就能让它抛 out of memory。encoding/gob 的文档也写明它没有针对对抗性输入加固。1213
• 它的信心来自 fuzz。 发版前要求测试覆盖率 ≥95%，覆盖率引导的 fuzz 要跑过数十亿次。12
• RFC 8949 把这件事写成了规范的一部分。 第 10 节的安全考量里，整数溢出和资源耗尽是明列的两条。14

复现难度：低

最小上手路径

mkdir cbor-demo && cd cbor-demo && go mod init demo
go get github.com/fxamacker/cbor/v2

package main

import (
  "fmt"

cbor "github.com/fxamacker/cbor/v2"
)

type S struct {
  Name string `cbor:"name"`
  N    int    `cbor:"n"`
}

func main() {
  b, _ := cbor.Marshal(S{"frank", 42})
  fmt.Printf("编码 %d 字节: % x\n", len(b), b)

var out S
  cbor.Unmarshal(b, &out)
  fmt.Printf("解回: %+v\n", out)

deep := []byte{0x9f}          // 0x9f = 不定长数组的开始
  for i := 0; i < 40; i++ {
    deep = append(deep, 0x9f)   // 再嵌 40 层
  }
  var v any
  fmt.Println("深嵌套:", cbor.Unmarshal(deep, &v))
}

编码 16 字节: a2 64 6e 61 6d 65 65 66 72 61 6e 6b 61 6e 18 2a
解回: {Name:frank N:42}
深嵌套: cbor: exceeded max nested level 32

今晚练习

1. 把 MaxNestedLevels 调到 4，再解一段 6 层嵌套的数组。本机报的是 exceeded max nested level 4，错误停在你设的那一层。12
2. 按 README 的 Security Tips，用 io.LimitReader 给一段不定长数据的解码套上整体大小上限。限制的是「一共读多少字节」，和嵌套层数、元素个数是两回事。12
3. 把 undefined（0xf7）解到一个 interface 变量里，看它是不是变成 nil；README 列的限制里就写着这一条。12

版本动作与限制

3. coregex：让耗时只跟输入长度有关

为什么今天看

最值得拆的机制

• 它把 Rust regex crate 的架构搬到了 Go。 Go 标准库的 regexp 是一个不优化的单一 NFA 引擎，换来 O(n) 的时间保证；coregex 保留 O(n)，在上面叠了 17 种引擎策略。16
• 编译分三段：解析 → NFA → 提取字面量 → 选策略。 运行期是「输入 → SIMD 预过滤 → 引擎 → 匹配结果」。16
• 预过滤是省时间的关键。 先在整段输入上用 SIMD 找可能匹配的起点，找不到就整段跳过。本机拿 IP 模式去匹配 7.4 MB 的纯英文文本，标准库要 140 毫秒，coregex 199 微秒；换成 .*error.*，标准库 138 毫秒对 coregex 169 微秒。16
• 反向搜索是另一类加速。 .*关键字.* 这类模式改成从后缀或内部字面量反向找，README 给的区间是 100 到 900 倍。16
• O(n) 的代价是不支持反向引用。 用了反向引用就没法保证线性时间，所以 coregex 直接不支持；(?i)、(?m)、(?s) 这些标志则照常支持。16
• 它的测试来自别的项目。 coregex 被拿去跑 GoAWK 的测试，找出 15 个以上合成基准测不到的边界问题；现在有一个基于它的 AWK 解释器 uawk。16

复现难度：低

最小上手路径

mkdir coregex-demo && cd coregex-demo && go mod init demo
go get github.com/coregx/coregex

package main

import (
  "fmt"
  "regexp"
  "strings"
  "time"

coregex "github.com/coregx/coregex"
)

func main() {
  pat := `\d+\.\d+\.\d+\.\d+`
  text := strings.Repeat("lorem ipsum dolor sit amet ", 300000) // 约 7.4 MB，一个数字都没有

std := regexp.MustCompile(pat)
  cg := coregex.MustCompile(pat) // 和 regexp 同一套 API

t0 := time.Now()
  std.FindAllString(text, -1)
  fmt.Println("标准库:", time.Since(t0))

t1 := time.Now()
  cg.FindAllString(text, -1)
  fmt.Println("coregex:", time.Since(t1))
}

标准库: 140.394ms
coregex: 199µs

今晚练习

1. 把你自己代码里的 regexp.MustCompile 换成 coregex.MustCompile，先跑一遍现有测试看行为是否一致。这个库的定位就是可以直接替换。16
2. 把发布说明里那个 15 个字符的模式 .(?:ac*d|ac)xy* 编一遍并计时。本机是 44 微秒，修复前它是几十秒。15
3. 用 coregex.CompileWithConfig 把 MaxDFAStates 调小，观察大输入上策略被换掉之后耗时怎么变。16

版本动作与限制

怎么选今晚的第一条路径