[sercebr]

#17 第 ④ 步：压缩变体表按句柄存/取

前三步把一条响应的体在走到 socket 之前的三次必付拷贝去掉了（① 静态层整份命中改递引用计数、
② 头体分两块交给 uv_write、③ uvcpp_buf 补上显式移动）。剩下热压缩响应上那最后一次：
变体表里那份压缩产物是表自己持有一份拷贝，命中时再拷一份回来。这一步把它换成一个句柄。

（这个 PR 基于 #19 合入后的 master；#19 里那两处注释里写着"今天仍然照拷……那就是第 ④ 步"，
现在到期了，一起改掉。版本号没动 —— 按你的习惯，合并之后你自己升一档。）

改了什么

compress_variant 的持有形状从 uvcpp_buf data 换成
::std::shared_ptr<const ::std::string> data，于是压出来的那份字节只存在一份：

1. 命中：resp.body.clear(); resp.body.clone(it->second.data); →
   resp.body.share(it->second.data); —— 递句柄，一个字节都不拷。（share() 顺手把静态层
   借来的那份放掉：既不物化、也不多一次拷贝。）
2. 压完：不再 clone(result.data) 进 resp.body，而是让产出落进一个共享串，响应与表
   共用它。这一份拷贝仍然在 —— 它是 deflate 的产出落进那个共享串（冷路径一次性的事）；
   ④ 去掉的是另外两份：存表那份、每次命中拷回来的那份。
3. 存表：存的就是上面那个句柄（以前 clone 一份，理由是"响应自己那份还要发出去，不能
   move 走"）。"不能 move"不等于"只能拷"，句柄把这句话兑现了。
4. 淘汰与上限：compress_variants_bytes_ 改用新的 bytes() 记账。这一处必须跟着换
   —— 忘了换的话字节账恒为 0，字节那条淘汰腿就静默瘸了（条数那条还在，所以"能淘汰"这件
   事不会立刻露馅，只在大文件上悄悄失效）。这条腿现在有自己的判据了，见下面 §自证 第三组。

表这边是 shared_ptr<const std::string>：拿不到可写指针。所以"共享出去之后被人改了"这件事由
uvcpp_buf 的静默物化兜着 —— 谁写谁自己拿到一份私有的，表里那份纹丝不动（下面有判据）。

实测（同一份二进制，一个环境变量分臂）

探针树上量的（六档里只有压缩那两档动）。两臂是同一份 uvcpp.dll：
UVCPP_VARIANT_HANDLE_OFF=1 时退回 ④ 之前的形状（存表再拷一份、命中拷回来），不设时表与响应
共用一个句柄。编译开关、链接、探针插点、机器状态全同一份，差值只能归给那几行。臂的物证是
服务端自己报的 variant_handle_off 与六档的逐档结构。

档位	上线字节/响应	④ 之前	④ 之后
静态 4 KiB 明文	4096	0.06×	0.06×
静态 248 KB 明文	253952	0.00×	0.00×
内存 4 KiB（不走静态层）	4096	1.03×	1.03×
静态 4 KiB + Range bytes=0-1023	1024	1.28×	1.28×
248 KB 压缩【冷】（20 个不同文件）	42896	2.01×	1.01×
248 KB 压缩【热】	42896	1.01×	0.01×

热那档降到 242 B/响应 —— 那是响应头本身，这一档到底了。冷那档剩的那一次 compress_out
仍在（deflate 产出的落点）。

报文的字节两臂 md5 相同（同一臂里冷热两次也相同）。这一条与性能判据是分开的：装置数的是
拷贝，这里钉的是"别把字节换掉了"。

自证（本机）

门禁请跑这个 SHA：60f4e84（已 rebase 到 b82c44a = 1.1.29，你的
c458be7「uvcpp_write 第 2 块槽位」之后）。

• ctest -C Release：79/79（本分支；perf(web): 响应体零拷贝接管（共享视图）+ 头体分两块写（nbufs = 2） #19 是 77/77。多出来的两个：本 PR 的新用例
  buf_share_handle_func，和你的 test_write_second_slot_func）。跑之前核过 exe 旁边那份
  DLL 与构建产物 md5 一致（见下面那个坑）。

• 按你 07:23/07:39 那条建议，我提了那条超时预算（tests/functional/CMakeLists.txt
  末尾，一条独立的 commit 60f4e84）：

  if(TARGET test_web_app_static_func)
    set_tests_properties(test_web_app_static_func PROPERTIES TIMEOUT 90)
  endif()

  机制本机两头复现了：ctest -C Release --timeout 1 -R test_web_app_static_func ⇒ 跑满
  16.89 s 通过；把属性暂时写成 TIMEOUT 2 再跑同一命令 ⇒ 当场 (Timeout)。也就是
  命令行那个数确实只是默认值，全局那 30 s 一点没松。if(TARGET ...) 是必须的：
  UVCPP_BUILD_WEBAPP 默认 OFF，那种配置下目标已被过滤器摘掉（拿 WEBAPP=OFF 的树实测过
  配置通过、目标确实不存在），不加守卫会报「找不到这个测试」。

  顺带把我在 CI 上量到的余量摆出来（c851ec2 那次，都是批处理之后的数）：ubuntu
  16.5 s / macOS 19.1 s / Windows web 21.4 s（上限 30 s）。所以它确实是最紧的那
  一条，而你说的"时红时绿"我这边的数据也支持：efad491 在 macOS 上 30.05 s 红，内容
  更多的 0d94f2e 反而全过。

• rebase 时在 web_app_static_func.cpp 撞了一处冲突，你那一版把 share_discard_count()
  的零拷贝记账块插在了 check(s.bytes > 0, ...) 后面，而那一句正是我换成"算死的账"的地方。
  解决方式是两侧都留：先是我的 sum_cl 断言，接着是你那段 share_discard_count 记账
  （连你那条独立对照一起），最后是那条 discarded == 0。两边的判据都还在、都跑绿。

• 新用例 tests/functional/buf_share_handle_func.cpp 守的是这件事带来的三条契约（都不是性能）：

  1. 命中那条路上两边指针相同 —— 判据用指针，不用"内容相等"（后者对"到底拷没拷"零信息量）；
  2. 谁写响应体都不许动到表里那份，而且分三种写法记各该记的账：直接写、追加 = 一次真物化
     （share_discard_count() +1）；clear() 之后再写（响应对象复用的正常序列）= 一个字节都没白
     拷，所以不记账（判据写成 +1 的话就是在钉一个错的账）；
  3. 淘汰时响应还没发完 —— ④ 之前这一条不可能出问题（那时两边各持一份拷贝），换成句柄之后它
     成了引用计数必须撑住的东西；反过来（响应先走、表里还在）同理。
     另外把 web_app_static_func 里那条 s.bytes > 0 换成算死的账：表内字节数必须正好等于那
     三次响应的 Content-Length 之和。

• 你要的那条腿（你 06:43 点名的）——test_variant_byte_account_on_evict：把条数上限跑满，
  存 1100 条（键不同、体完全一样，于是每条压缩后都是同一个长度 C），淘汰开始之后两条腿分开钉：

  • 条数腿：表里稳定在 1024 条（kCompressVariantMaxEntries）；
  • 字节腿：账必须 == 剩余条数 × C。

  这是你要的那个形状 —— 钉的是"那个上限存在"，不是一个恰好相等的数。旧的
  test_compress_variant 只有三条 entry、一次淘汰都没发生（bytes = 124 是三次响应长度之和），
  所以它对"淘汰时少减一次"零信息量。新用例补的就是这中间那段。

  这条用例要真打 1100 条请求，而 CI 那条 --timeout 30 是硬线，所以形状是量出来的：
  每批 20 条走一条连接（批内最后一条带 Connection: close），0.37 秒。中间试废的两版：
  一请求一连接（正确，但 Windows 上每条连接约 4 ms ⇒ 4.5 秒，这个 PR 的第一版就是这么把
  macOS CI 顶超时的）；一口气灌 1100 条（0.2 秒，但会丢请求 —— 见下）。

• 变异验证（改一行、跑、再改回来，每次往返逐字节核对过）：

  1. bytes() 归零 → "表内字节数 == 三条变体的压缩长度之和"那条红；

  2. 命中那条路递空句柄 → 三条红，其中就有"第二次的字节与第一次逐字相同"；

  3. 删掉 compress_variant_evict() 里的 compress_variants_bytes_ -= victim->second.bytes();
     → 新用例 bytes = 47300 = 1100 × 43（应为 1024 × 43 = 44032）红；而条数腿照样绿
     （entries = 1024）、旧的 test_compress_variant 也照样绿（bytes = 124 不变）。
     正是"一个仍会通过的旁路判据把主判据的失效盖住"那个形状 —— 你认的那条。

     这条变异第一遍跑出来是假绿：单目标构建没刷新测试目录里那份 DLL（copy_test_dlls 是个
     ALL 目标），编出来的 exe 配的还是旧 DLL，读数一点没变。核 md5 才发现，走全量构建才复现。
     记在这，免得别人也踩。

顺带撞到一个别的问题：跨 64 KiB 边界的请求会被丢掉

为了让这条用例跑得进 30 秒，我先试过"把 1100 条一口气灌进同一条连接"（HTTP 流水线）。
它丢请求，而且 100% 可复现 —— 所以这条用例改成小批灌入绕开它，但问题本身该报给你：

• 1100 条 GET /vb/<i>（全 keep-alive，末尾跟一条 Connection: close 的终止请求）打进一条连接：
  1101 条里固定丢第 745 条。它的字节区间是 65450..65538，正好盖住 65536。
  服务端回 1099 条 /vb/ 的响应，那一条既没有响应、也没有进变体表（stored 也是 1099）。
  连跑三次，每次都是 745。
• 给每条请求加 19 字节填充（把边界挪走）：丢的变成新的跨界那条（586，区间 65522..65634），
  而且它之后整段都不回（只回了 586 条）。跟着边界走 ⇒ 不是"某一条请求有问题"。
• 服务端的读缓冲是 64 KiB（uvcpp_tcp_client::internal_alloc_cb 用的是 libuv 建议的尺寸），
  所以"跨在单次 read 边界上的请求"被丢，看起来是解析累积那一侧的问题，不是 TCP 的事。

这一条不在本 PR 的范围里，也没有被本 PR 的判据碰到（用例改成每批 20 条之后每条都回、
每条都存）。要不要我给它单开一个 issue、再补一条最小的复现用例（比如"一条连接里第一
条请求故意跨 64 KiB"），你说一声。

三点想请你评审的地方

1. bytes() 是这一版唯一"容易忘"的地方。 它没有任何编译期保护（data 从 uvcpp_buf 换成
   了 shared_ptr，data.size() 这种写法会编不过，但字节账写成常量 0 照样编得过）。现在有
   一条只钉字节腿的用例了（上面第三条变异证明它单独能红、且条数腿红不了）。不过那是运行时
   的兜底 —— 如果你觉得该在类型上再收紧（比如让 compress_variants_bytes_ 只能由 bytes() 增减），
   说一声我改。
2. 你 06:43 提的 ② 那处重叠：按你说的，④ 照开、不为此改。④ 合了之后压缩命中那条路上的
   受害者就没了，② 拿别的调用点做判据 —— 这里只是把这件事再确认一遍，免得我理解偏了。
3. 命中/存表两处现在共享同一块字节，于是"能不能改"从一个实现细节变成了契约。 我按你 04:22
   那条的口径落的：静默物化 + 计数器，不硬断言。新用例把三种写法的账都钉了（含"clear()
   之后再写不记账"这条 —— 它记的是白拷，而 clear() 一个字节都没拷）。

[Antruly]

已合入 master：merge commit dcfbd27（父提交 10c0230 + 60f4e84），
版本跟着升到 1.1.31（86ed312）。

不是走 GitHub 的合并按钮，而是本地 --no-ff 合并之后推的（本仓 #9、#19 都是这么落的）——
这样页堆门禁的结论能落在真正被推上去的那个 SHA 上，而不是先用按钮合、再补验证。

验证与讨论都在 #17：本机全量 build-webapp 80/80、build-h2 91/91、完整页堆门禁 rc=0、
86ed312 的 CI 18/18 全 success。head 分支 perf/variant-handle 你留着或删都行。