二维码载荷硬预算与最长真实载荷验证
一句话:URL 进二维码后每个字符都占物理密度——可选数据必须”按硬预算上车、超了逐级丢”,且验证必须用最长真实载荷;调试捷径产生的短数据会系统性掩盖超限 bug。
事故
《镜像自我》扫码报告链路:给扫码载荷加了两个”锦上添花”字段（读心印象小标题 + 总结）,用调试直跳（空轨迹,987 字符）验证”可扫”后上线。真实一局是 8 个选择节点 + AI 叙事全文——载荷 1189 字符,QR 从 v22 跳到 v25（117×117 模块）,海报 176px 框位每模块只剩 2.8px,现场手机扫不开。
原理
- QR byte 模式 ECC L 容量阶梯:v22=1003 / v23=1091 / v25=1273 字节;版本每升一级,同框位下每模块像素被摊薄
- 中文经 deflate 压缩率低（UTF-8 3 字节/字、熵高）,叙事全文是不可压缩的底盘;可选字段的每个字都在挤压码的物理余量
- 实测可扫基线以框位×版本为单位记录（本项目:176px 框位 ≤v23 可扫,主导实测）
操作规则
- 定硬预算常量并把依据写进注释（如
QR_URL_BUDGET = 1090 // v23 容量,176px 框位实测可扫基线） - 降配序列按价值排序:核心内容（叙事全文）永不降;可选字段逐级丢（总结 → 小标题 → 时间线截短 → 时间线丢弃）,循环取第一个进预算的变体
- 物理兜底:最后一档仍可能超预算——码框位按 URL 长度自适应放大（176/184/208px,密度守恒）,大框位时注意与相邻版面元素的碰撞
- 验证用顶格数据:写验证脚本先问”这个数据的真实最大形态是什么”（最长标题+最多节点+最长 AI 文本）,凡有长度/密度上限的功能（二维码/短信/推送/文件名）都适用
边界
- 短链服务可根治载荷问题,但离线展台原则不允许外部依赖
- 屏幕扫码（亮度高、对比强）的密度容忍度高于印刷/成图,以最差介质定基线
关联文档
- 2026-07-14_镜像自我_镜中特写AI读心_迭代复盘 —— 案例母档
- 2026-07-09_镜像自我人生预演_36h极限开发复盘 —— 同项目扫码链路的初建背景
- OpenAI区域封锁与Worker就近执行陷阱_北美DO跳板_v1 —— 同项目次日的线上侧踩坑(区域封锁与跳板)