perf(c-core): 完全 C 化 + 消灭初版的 malloc/拷贝开销(C 从「更慢」变「明显更快」)

上一提交的基准结论是错的:"C 比 Go 慢" 不成立 —— 那是我把自己的
malloc/拷贝开销误当成了 cgo 的固有成本。本提交先拆解成本、再逐项消灭。

## 成本拆解(同机、百万次 benchtime)

| 场景 | ns/op |
|---|---:|
| cgo 边界(零拷贝传指针 + 空函数体)| 31.9  ← cgo 真实固有成本 |
| + 一次 C.CString + C 侧 strlen | 105-111(多出 ~75ns)|
| 初版 ModelContextWindow(另加 lower_dup malloc + 16×strstr)| 175 |

即 82% 开销是自找的。而初版还违反了自己写在设计文档 §四 的原则第 1 条
「C 接口只吃 const char* + 长度」——它没传长度,让 C 侧 strlen 再扫一遍。

## 逐项修复

1. C.CString(malloc+整串拷贝)→ unsafe.StringData 传指针+长度,零拷贝
2. C 侧 strlen 再扫一遍 → 长度由调用方传入,不扫
3. truncate 的 malloc 输出缓冲 + GoStringN 拷回 → C 只返回**字节数**
   (结果必然是输入前缀),Go 侧 s[:n] 完成切片,全程零分配
4. lower_dup 每次 malloc 模型名 → 栈缓冲折叠,超长走零分配回退
5. 逐字节 utf8_next 函数调用 → 字级(8 字节)ASCII 检测
6. truncate 扫完整串才判断 → 数满 keep 个 rune 立即返回(提前短路)
7. 纯 Go 侧 len([]rune(s))/[]rune(s)(1KB 分配 4KB)→
   utf8.RuneCountInString / DecodeRuneInString 游走,零分配

## 结果

| 基准 | 初版 C | 优化后 C | 纯 Go | 提升 |
|---|---:|---:|---:|---:|
| ModelContextWindow | 175 | 76.5 | 46.8 | 2.3× |
| EstimateTokens / 1KB ASCII | 2318 | 80.8 | 326 | 28.7× |
| TruncateByTokens / 1KB ASCII | 2594 | 71.7 | 411 | 36× |
| TruncateByTokens / 1KB 中文 | 3923 | 70.1 | 3097 | 56× |

## 完全 C 化(jianf 裁定)

撤掉我一度加的「短串 <32B 走回 Go」按长度分派:那会同时存在两份语义
可能分叉的实现。C 是唯一实现。

代价如实记录:EstimateTokens("qq") 这类极短串上 C 约 47ns(几乎全是
31ns 边界成本)vs 纯 Go 约 3ns,慢约一个数量级;绝对值纳秒级
(0.000047ms),单次请求尺度可忽略。若某循环对极短串高频调用,
正确应对是**把该循环 C 化(批量传一次)**,而不是按长度分派回 Go。

## 顺带补的正确性缺口(初版是真错的)

初版 C 的 UTF-8 解码只按首字节推断长度、**不校验后续字节**,
因此对畸形序列会与 Go 分叉:例 "\xE4\x41\x41",Go 判 3 rune,
初版判 1 rune ⇒ rune 计数偏差 ⇒ token 预算与截断点偏移。
这类偏差**只影响计数、不会崩**,不测发现不了。

现在 C 侧做与 utf8.DecodeRuneInString 等价的完整校验(含过长编码、
代理对、超 U+10FFFF、截断序列),语义边界逐条注释。
代价:中文密集输入比初版慢(1467 vs 840)—— 这是刻意的正确性代价,
且仍比纯 Go 快 2×。

新增测试:
- TestGolden_InvalidUTF8:3000 组**任意字节**(含畸形序列)对拍,
  覆盖初版会分叉的输入类别
- TestGolden_TruncateAlwaysPrefix:截断结果必为原串前缀且不超长
- C 契约测试从 21 项扩到 40 项(含非 NUL 结尾、超长名、畸形 UTF-8)

## 包现在要求 cgo 才能编译

删除 codec_nocgo.go:CGO_ENABLED=0 下整包构建失败(错误直指缺失符号)。
不保留回退的理由:只验证过一条路,就不该存在第二条。
实测这不影响任何构建 —— go list -deps 证明只有 cmd/homed 依赖本包,
而 waiter/initconfig/memgc/mock-server 均不依赖(逐个验过),
且 homed 本就强制 cgo(sqlite3 + gojieba)。仓库无 CI。

Makefile 把「不许有第二条路」变成可执行断言:check-codec-cgo-only
(断言 cgo 下全绿 **且** CGO_ENABLED=0 下必须失败)。

## 验证

- C 契约测试 40/40(gcc -Wall -Wextra 零警告)
- 黄金对照 6 个测试全绿(含 2000 组随机 + 3000 组畸形字节对拍)
- 变异测试:改 C 侧返回值后 go test 立即 FAIL(确认真的走 C)
- make check-codec-cgo-only 两项断言通过
- go vet ./... 干净;全量 go test -count=1 ./... → 38 ok / 0 FAIL

## 已知既有 flaky(与本改动无关,单独记录)

internal/plugins 在全量并发下偶发一次 SIGSEGV,栈在
internal/plugin/proc/{unified.go:234,arena.go:197}(arena 的 getU32)。
该两文件最后修改于 09-10,本提交 0 处触及;随后连跑 5 次单包 +
2 次全量均通过。初步判断是 arena/shared-region 的既有竞态,需单独排查。
This commit is contained in:
JianFeeeee
2026-09-25 15:40:20 +08:00
parent 5ccdf24f18
commit 7799ca4559
11 changed files with 912 additions and 340 deletions

View File

@ -3,12 +3,15 @@ package api
// codec.go —— 编解码层的**统一出口**(无论 CGO 开关如何,调用方只认这里)。
//
// 分层:
// codec_pure.go —— 纯 Go 实现,永远参与编译(回退 + 黄金对照基准)
// codec_cgo.go —— CGO_ENABLED=1:真正调 C 库
// codec_nocgo.go —— CGO_ENABLED=0:把 C 符号转发到纯 Go
// codec_cgo.go —— C 实现绑定(要求 cgo;CGO_ENABLED=0 下整包构建失败)
// codec_pure.go —— 纯 Go **参考实现**:只作黄金对照的规格基准,
// 不是生产路径(不带 build tag,永远参与编译)
// codec.go —— 本文件:对外的稳定 API,含兜底与日志
//
// 这样调用方(provider.go / core)不需要写任何 build tag 分支。
//
// ★ 编解码层已「完全 C 化」:C 是唯一实现,不存在 CGO_ENABLED=0 回退。
// 理由(防两条语义分叉的实现同时跑)见 codec_cgo.go 顶部。
import (
"log"
@ -34,9 +37,11 @@ func ModelContextWindow(model string) int {
// EstimateTokens 粗略估算 token 数。
//
// 注意:这是**高频热路径**(上下文裁剪对每个事件都调)。走 C 的跨语言开销
// 对短文本未必划算 —— 是否该留在 C 侧由 codec_bench_test.go 的实测数据决定,
// 不要凭直觉断言(见 docs/zh/c-core/llm-orchestration-c.md §七 未决问题 3)。
// 注意:这是**高频热路径**(上下文裁剪对每个事件都调)。已完全 C 化,
// 但 cgo 边界固有成本约 30ns ⇒ 极短串上比直调纯 Go 慢(纳秒级,见
// codec_bench_test.go 的实测与 docs/zh/c-core/llm-orchestration-c.md §7.1)。
// 若某循环对极短串高频调用,正确应对是**把该循环 C 化(批量传一次)**,
// 而不是按长度分派回 Go —— 那会引入第二条可能分叉的实现。
func EstimateTokens(text string) int { return estimateTokensC(text) }
// TruncateByTokens 截断字符串至不超过 maxTokens 估计值。

View File

@ -18,29 +18,44 @@ package api
// **不能链接预构建静态库**(`LDFLAGS: .../csrc/build/libha_codec.a`):
// - .a 是构建产物、不入库(.gitignore 的 build/ 命中 csrc/build/),
// 而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空,链接必然失败
// (实测:cannot find csrc/build/libha_codec.a)
// - 交叉编译 linux/arm64(homed 的真实发布目标)时,宿主 x86-64 的 .a
// 被链进目标产物,报 `file in wrong format`(实测)。
// 被链进目标产物,报 `file in wrong format`
//
// **不能用 `#include "../../../csrc/src/ha_codec.c"`(包外相对包含)**:
// ★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测:在包外源里把
// 返回值从 7 改成 8,`go test` 依然通过(缓存命中,静默沿用旧代码);
// 而同样改动落在包内文件时立刻判红。这对「逐步推进 C 化」是致命的——
// 改 C 源码却不生效,且无任何报错。
// ★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测:包外源把返回值
// 7 改成 8,`go test` 依然通过(缓存命中、静默沿用旧代码);同样改动落在
// 包内文件时立即判红。这对「逐步推进 C 化」是致命的——改 C 源码却不生效
// 且无任何报错。
// (包内 shim `#include` 包外源同样漏跟踪,已实测排除。)
//
// 包内符号链接同时满足两点:文件在包目录内 ⇒ 缓存按内容正确跟踪;
// 只有一份权威源 ⇒ 无副本漂移,也不需要「同步 C 源」的 make 目标。
//
// ============================ 零拷贝:不 CString、不 strlen ============================
// ★ 这是**被实测教训倒逼出来的**(见 docs/zh/c-core/llm-orchestration-c.md §7.1):
//
// cgo 边界的固有成本实测约 **32 ns**(零拷贝传指针 + 空函数体)。
// 而初版每次调用都做 `C.CString`(malloc + 整串拷贝)+ C 侧 `strlen`(再扫一遍),
// 单这一项就约 **75 ns**,加上 C 侧 `lower_dup` 的 malloc 与逐字节扫描,
// 使 ModelContextWindow 实测达到 **175 ns** —— 即 **82% 是自找的开销**,
// 而非 cgo 的固有代价。初版由此得出「C 比 Go 慢」的结论是**错的**。
//
// 现在:Go 侧用 `unsafe.StringData` 把 string 的底层字节**直接**交给 C
// (传指针 + 长度),C 侧不 malloc、不 strlen、不要求 NUL 结尾。
// 截断则只回**字节长度**(结果必然是输入前缀),Go 侧 `s[:n]` 完成切片,
// 全程零分配零拷贝。
//
// 边界与安全:
// - 不把 Go 指针交给 C 长期持有(C 侧不保存任何指针,纯函数)
// - 空串在 Go 侧短路,不把可能的 nil 指针传下去
// - cgo 规则允许传「不含 Go 指针的内存」的指针,string 底层字节满足
//
// ============================ 为什么不需要额外 build tag ============================
// 与 onnxruntime(internal/nlp/onnx.go,需运行期 libonnxruntime.so)不同:
// ha_codec 是**零依赖纯 C99 源码内联编译**,不需要任何外部库或工具链前提。
// 而 homed 本就强制 cgo(mattn/go-sqlite3 + gojieba),故 C 路径自然生效。
// 因此只用 `cgo` / `!cgo` 一组约束,不引入 hacodec tag。
//
// ============================ C 侧契约 ============================
// `#include "ha_codec.h"` 只声明原型;实现在同包的 ha_codec.c,由 cgo 自动编译。
// 只含 libc 头,不引入第三方符号。
// 因此只用 `cgo` 约束(**没有 `!cgo` 回退**:CGO_ENABLED=0 下本包构建失败,
// 这是有意的响亮失败,理由见上),也不引入 hacodec tag。
//
// 语义必须与 codec_pure.go 逐值等价,由 codec_golden_test.go 钉死。
@ -53,45 +68,49 @@ import "C"
import "unsafe"
// cstr 返回 s 的底层字节首地址与长度,供 C 侧零拷贝读取。
//
// 空串返回 (nil, 0):调用方不应把 nil 传给会解引用的 C 函数。
func cstr(s string) (*C.char, C.size_t) {
if len(s) == 0 {
return nil, 0
}
return (*C.char)(unsafe.Pointer(unsafe.StringData(s))), C.size_t(len(s))
}
// modelContextWindowC 经 C 实现推断上下文窗口。
func modelContextWindowC(model string) int {
cModel := C.CString(model)
defer C.free(unsafe.Pointer(cModel))
return int(C.ha_codec_model_context_window(cModel))
p, n := cstr(model)
return int(C.ha_codec_model_context_window(p, n))
}
// estimateTokensC 经 C 实现估算 token 数。
//
// ★ 不做按长度分派:**完全 C 化**——compute 一律走 C,纯 Go 实现不再是
// 生产路径(只作为黄金对照的规格基准)。
//
// 代价(如实记录,勿用「C 更快」一句话盖过):cgo 边界固有成本实测约 30ns,
// 故对「极短串」(如 2 字节的 "qq")本函数约 30ns,而直调纯 Go 仅约 3ns
// ——即极短输入上 C 路径约慢一个数量级,但绝对值是**纳秒级**
// (30ns = 0.00003ms,单次请求尺度可忽略)。
// 换来的是:单一实现、无静默分派分叉、C 侧对畸形 UTF-8 的严格校验恒生效。
func estimateTokensC(text string) int {
cText := C.CString(text)
defer C.free(unsafe.Pointer(cText))
return int(C.ha_codec_estimate_tokens(cText))
p, n := cstr(text)
return int(C.ha_codec_estimate_tokens(p, n))
}
// truncateByTokensC 经 C 实现按 token 截断。
//
// 缓冲区策略:按 rune 数上界分配(每个 rune 最多 4 字节)+ 1 字节 NUL,
// 保证 C 侧不会因容量不足而截短——否则 C 与 Go 的逐值对照会假失败。
// 若字符串无 rune(纯 ASCII 也至少 len 字节),取 len(text)+1 兜底。
// C 侧只返回「应保留的字节数」——截断结果必然是输入的前缀,
// 故这里直接切片,无需缓冲区、无需 malloc、无需把结果拷回来。
func truncateByTokensC(s string, maxTokens int) string {
if maxTokens <= 0 || s == "" {
return ""
}
// []rune 的长度即 rune 数;每个 rune 最坏 4 字节,+1 给 NUL。
runeCount := len([]rune(s))
bufSize := runeCount*4 + 1
if bufSize < len(s)+1 {
bufSize = len(s) + 1
p, n := cstr(s)
keep := C.ha_codec_truncate_by_tokens(p, n, C.int(maxTokens))
if uint64(keep) >= uint64(len(s)) {
return s
}
buf := (*C.char)(C.malloc(C.size_t(bufSize)))
if buf == nil {
// 分配失败:回退纯 Go 实现,不让整个调用失败。
return truncateByTokensPure(s, maxTokens)
}
defer C.free(unsafe.Pointer(buf))
cText := C.CString(s)
defer C.free(unsafe.Pointer(cText))
n := C.ha_codec_truncate_by_tokens(cText, C.int(maxTokens), buf, C.size_t(bufSize))
return C.GoStringN(buf, C.int(n))
return s[:int(keep)]
}

View File

@ -1,14 +1,13 @@
package api
// codec_golden_test.go —— 黄金对照测试:C 实现与纯 Go 实现必须逐值等价。
// codec_golden_test.go —— 黄金对照测试:C 实现与纯 Go 参考实现必须逐值等价。
//
// 这是本轮 C 化**最重要的验收**(见 docs/zh/c-core/llm-orchestration-c.md §五)。
// 这是 C 化**最重要的验收**(见 docs/zh/c-core/llm-orchestration-c.md §五)。
// 没有它,「C 化没坏」就只是感觉,不是证据。
//
// 两条约束:
// 1. CGO_ENABLED=1 时:真的对比 C 与纯 Go 两条路径
// 2. CGO_ENABLED=0 时:C 符号已转发到纯 Go,对照退化为自比(仍跑,防止
// 测试文件因 build tag 被整文件跳过 —— 那会让 0 模式下失去这段覆盖)
// 运行前提:**CGO_ENABLED=1**。内核已完全 C 化:本包**要求 cgo 才能编译**
// (无 !cgo 回退文件),故 CGO_ENABLED=0 时整包构建失败 —— 这是有意的
// 响亮失败,见 codec_cgo.go 顶部与 Makefile 的 check-codec-cgo-only。
import (
"math/rand"
@ -113,3 +112,68 @@ func TestGolden_Randomized(t *testing.T) {
}
}
}
// TestGolden_InvalidUTF8 用**任意字节**(含畸形序列)对比 C 与纯 Go。
//
// 为什么必须有:C 侧的解码必须与 Go 的 utf8.DecodeRuneInString 完全同语义
// ——尤其是「无效/截断序列只前进 1 字节」(Go 返回 RuneError 且 size=1)。
// 若 C 侧放宽校验,两侧 rune 计数就会分叉,而合法 UTF-8 的测试**抓不到**这个。
// 这是 C 化最容易出错、也最容易被漏测的地方。
func TestGolden_InvalidUTF8(t *testing.T) {
// 覆盖各类边界字节:续字节、过长编码、代理对、超出 U+10FFFF、截断序列。
seed := []byte{
0x00, 0x41, 0x7F, 0x80, 0xBF, 0xC0, 0xC1, 0xC2, 0xDF, 0xE0, 0xE1,
0xED, 0xEF, 0xF0, 0xF1, 0xF4, 0xF5, 0xF8, 0xFE, 0xFF,
0xE4, 0xBD, 0xA0, // 你
0xF0, 0x9F, 0x98, 0x80, // 😀
0xED, 0xA0, 0x80, // 0xED 0xA0 0x80 = UTF-16 代理对,非法
0xC0, 0x80, // 过长编码 NUL,非法
0xF4, 0x90, 0x80, 0x80, // > U+10FFFF,非法
}
rng := rand.New(rand.NewSource(20260925))
for i := 0; i < 3000; i++ {
n := rng.Intn(24)
b := make([]byte, n)
for j := range b {
if rng.Intn(3) == 0 {
b[j] = byte(rng.Intn(256)) // 完全随机字节
} else {
b[j] = seed[rng.Intn(len(seed))]
}
}
s := string(b)
if c, p := estimateTokensC(s), estimateTokensPure(s); c != p {
t.Fatalf("EstimateTokens(%q) 畸形输入: C=%d, pure=%d", b, c, p)
}
// 截断也必须落在同一字节边界上(不得切在字符中间,且两侧一致)
mt := rng.Intn(40) - 2
if c, p := truncateByTokensC(s, mt), truncateByTokensPure(s, mt); c != p {
t.Fatalf("TruncateByTokens(%q, %d): C=%q, pure=%q", b, mt, c, p)
}
}
}
// TestGolden_TruncateAlwaysPrefix 不变量:截断结果必须是原串前缀,且 <= 原长。
func TestGolden_TruncateAlwaysPrefix(t *testing.T) {
inputs := []string{
"", "a", "abc", "你好世界", "a你b好c", "😀😀😀", strings.Repeat("x", 300),
strings.Repeat("中", 300), "\xe4\xbd", "a\xed\xa0\x80b",
}
for _, s := range inputs {
for mt := -2; mt <= 60; mt++ {
got := truncateByTokensC(s, mt)
if !strings.HasPrefix(s, got) {
t.Fatalf("TruncateByTokens(%q, %d)=%q 不是原串前缀", s, mt, got)
}
if len(got) > len(s) {
t.Fatalf("TruncateByTokens(%q, %d) 结果长于输入", s, mt)
}
if got != truncateByTokensPure(s, mt) {
t.Fatalf("TruncateByTokens(%q, %d): C=%q, pure=%q", s, mt, got, truncateByTokensPure(s, mt))
}
}
}
}

View File

@ -1,22 +0,0 @@
//go:build !cgo
package api
// codec_nocgo.go —— CGO_ENABLED=0 时把 C 路径的符号指向纯 Go 实现。
//
// 为什么需要这层转发而不是直接调 *Pure:让 codec.go 无论编译开关如何都能引用
// 同一组符号名,避免调用方到处写 build tag 分支。
//
// 谁会走到这里(CGO_ENABLED=0):
// - waiter 等刻意 CGO-free 的跨平台目标(Makefile build-cli)
// - 交叉编译到无 cgo 工具链的场景
//
// homed 不会走到这里——它强制 cgo(sqlite3 + gojieba)。
// 两条路径的语义等价由 codec_golden_test.go 钉死,Makefile 的
// check-codec-paths 目标同时跑两条。
func modelContextWindowC(model string) int { return modelContextWindowPure(model) }
func estimateTokensC(text string) int { return estimateTokensPure(text) }
func truncateByTokensC(s string, maxTokens int) string { return truncateByTokensPure(s, maxTokens) }

View File

@ -1,16 +1,30 @@
package api
// codec_pure.go —— 编解码层的**纯 Go 实现**,永远参与编译。
// codec_pure.go —— 编解码层的**纯 Go 参考实现**。
//
// 它有两个身份:
// 1. CGO_ENABLED=0 时的生产实现(Windows 包走这里,见
// deploy/packaging/package-windows.sh:69)
// 2. CGO_ENABLED=1 时**黄金对照的基准**(codec_golden_test.go 用同一组输入
// 对比它与 C 实现,逐值必须相等)
// ★ 这**不是生产路径**。内核已「完全 C 化」:所有调用都走 C
// (internal/agent/api/codec_cgo.go),本文件只服务两个目的:
//
// 因此本文件**不带 build tag**——两条路径都要能见到它。
// 1. **规格基准**:`codec_golden_test.go` 用同一组输入对比它与 C 实现,
// 断言逐值相等。C 侧的任何语义偏差(尤其畸形 UTF-8 的解码边界)
// 都由它抓出。没有它,「C 化没改错」就只是感觉。
// 2. **可读的规格**:C 是命令式字节游走,Go 版是直白的语义陈述。
// 两者并读时,改哪边都能立刻看出另一边该怎么改。
//
// 因此本文件**不带 build tag**,永远参与编译(测试要能引用)。
// 但没有任何生产代码路径调用它:编解码层要求 cgo 才能编译
// (CGO_ENABLED=0 下整包构建失败,见 codec_cgo.go 顶部)。
//
// ★ 零分配:本文件刻意不用 `len([]rune(s))` / `[]rune(s)`。
// `[]rune(s)` 会分配 4×len 字节的临时切片(1KB 字符串就是 4KB 垃圾),
// 而 rune 计数与「前 keep 个 rune 的字节边界」都能用
// utf8.RuneCountInString / utf8.DecodeRuneInString 游走完成,零分配。
// 实测这曾使纯 Go 的 TruncateByTokens 在 1KB 中文上分配 4208 B/2 allocs。
import "strings"
import (
"strings"
"unicode/utf8"
)
// defaultInferredContextWindow 是模型名无法推断窗口时的兜底。
//
@ -29,6 +43,9 @@ const contextWindowUnknown = -1
// modelContextWindowPure 由模型名推断最大上下文窗口;推断不出返回哨兵。
// 标称窗口 ≠ 有效窗口:接近满时注意力涣散,调用方应取 70-80% 为目标利用率。
//
// ★ 分支顺序即语义:先匹配者胜出(例:gpt-4-turbo 必须先于裸 gpt-4)。
// C 侧 ha_codec_model_context_window 必须保持同一顺序。
func modelContextWindowPure(model string) int {
model = strings.ToLower(model)
switch {
@ -71,11 +88,14 @@ func modelContextWindowPure(model string) int {
// estimateTokensPure 粗略估算 token 数。
// 中文 ~1.5 token/字,英文 ~0.3 token/字符,保守估计取 max(1, runeCount * 2)。
//
// 用 RuneCountInString 而非 len([]rune(text)):后者会分配 4×len 字节。
// 两者对**畸形 UTF-8** 的计数一致(无效字节各计 1 个 rune)。
func estimateTokensPure(text string) int {
if text == "" {
return 0
}
runeCount := len([]rune(text))
runeCount := utf8.RuneCountInString(text)
if runeCount == 0 {
return 0
}
@ -87,17 +107,26 @@ func estimateTokensPure(text string) int {
}
// truncateByTokensPure 截断字符串至不超过 maxTokens 估计值。
//
// 语义(与 C 侧一致):未超预算则原样返回;否则保留前 maxTokens/2 个 rune。
// 结果必然是输入的前缀,故直接按字节边界切片——无需构造 []rune。
func truncateByTokensPure(s string, maxTokens int) string {
if maxTokens <= 0 || s == "" {
return ""
}
runes := []rune(s)
if len(runes)*2 <= maxTokens {
runeCount := utf8.RuneCountInString(s)
if runeCount*2 <= maxTokens {
return s
}
keep := maxTokens / 2
if keep >= len(runes) {
if keep >= runeCount {
return s
}
return string(runes[:keep])
// 游走到「前 keep 个 rune」的字节边界(零分配)。
n := 0
for count := 0; count < keep; count++ {
_, size := utf8.DecodeRuneInString(s[n:])
n += size
}
return s[:n]
}