鸿蒙 PC Markdown 编辑器 Beta 质量门禁与千文件压力

仓库地址：https://gitcode.com/VON-/codex_md_oh

代码基线：G3-09 设备收口 fc7de5a，G3-10 第一质量纵切 941a1dc。

Beta 质量不是把测试数量写大

Markdown 编辑器从 Alpha 进入 Beta，最大的变化不是又多了几个按钮，而是已有能力开始面对规模、组合和长期使用。单文件打开通过，不等于一千文件工作区仍能搜索；五兆字符能触发保护模式，不等于十兆字符不会在状态计算中复制全文；一次恢复成功，也不等于高频操作后仍没有数据丢失。

OhMarkdown 的 G3-10 将质量工作分成内部可重复基线和外部真实证据。内部基线可以由工程环境完成：全量自动化、精确大文档、模拟器工作区压力、原生服务测试、依赖审计和安全边界。外部证据必须等待真实条件：竞品统一任务、鸿蒙 PC 真机、物理键鼠、50-100 人封闭测试和长期强杀。两类证据不能互相冒充。

本轮完成的是第一类。Playwright 从 43 项增加到 44 项；ohosTest 从 9 项增加到 10 项；新增精确 10 MiB Web 保护模式与 1000 文件模拟器搜索。结果全部通过，但项目进度仍保持 G3 8/10，因为一个小阶段通过不等于整个 Beta 评审退出。

先把门禁变成统一入口

项目使用 scripts/verify-local.sh 串联 Web、HAP、ArkTS 和 diff 检查。核心脚本保持简单：

"$ROOT_DIR/scripts/verify-web.sh"
"$ROOT_DIR/scripts/build-debug.sh"

"$DEVECO_HOME/tools/hvigor/bin/hvigorw" \
  UnitTestBuild \
  --mode module \
  -p product=default \
  -p module=entry@default \
  -p buildMode=test \
  -p unitTestMode=true \
  --no-daemon

git diff --check

统一入口的价值是让一次变更不能只挑对自己有利的用例。新增 1000 文件原生测试时，仍要跑渲染、右键、快捷键、导出和大文档；修改 Web 大文件策略时，仍要证明 ArkTS 可以构建。门禁不是追求一条命令的仪式感，而是减少“局部通过、整体破坏”的机会。

Playwright 临时服务器需要本机端口权限，HarmonyOS 构建依赖 DevEco Studio JBR 与 SDK。报告必须记录这些环境条件，避免 CI 端口失败被误写为产品失败，也避免本地构建成功被误写成 GitCode Runner 已通过。

十兆字节为什么必须精确构造

旧用例用 'a'.repeat(5 * 1024 * 1024) 验证保护模式阈值，能证明边界触发，却不能覆盖 PRD 指定的 10 MiB。新用例在浏览器页面内部构造精确 10,485,760 个 UTF-16 字符，避免把 10 MB、10 MiB 和 UTF-8 字节混成同一个概念。

const targetLength = 10 * 1024 * 1024;
const line = '鸿蒙PC大文档\n';
const content = line
  .repeat(Math.ceil(targetLength / line.length))
  .slice(0, targetLength);
const startedAt = performance.now();
host.OhMarkdownEditor.setDocument(content);
host.OhMarkdownEditor.setMode('preview');

第一次实现曾用人工估计的“每行九字符”计算重复次数，实际得到 9,320,680 字符，测试立即失败。修正后使用 line.length 作为事实来源，再 slice 到目标长度。这次失败很有价值：它说明性能语料也需要精确校验，不能仅凭文件名或生成公式宣称是 10 MiB。

用例随后检查三件事：getDocument().length 必须完全相等；工作区 mode 必须仍为 source；操作耗时小于 3000 ms。编辑器和预览可见性也分别断言，防止状态属性正确但布局没有同步。

大文档保护模式保护的是什么

五兆字符以上，OhMarkdown 使用 CodeMirror minimalSetup，不加载 Markdown 语言扩展与自动换行；预览、专业渲染、HTML、PDF、PNG、链接助手和周期恢复快照停止。字数返回 -1，原生状态栏显示大文件模式。目的不是“功能缩水”，而是把用户最重要的源码编辑和保存留在可响应范围内。

保护模式必须在 setDocument 创建 EditorState 时生效，而不是等到第一次输入后才切换。否则 10 MiB 文档会先完成高成本语法树、行包装和预览，再补救已经发生的内存峰值。当前 createEditorState 根据 content.length 直接选择 minimalSetup，后续 transaction 仍调用 updateLargeDocumentMode 保持一致。

本轮 Chromium 页面内 setDocument、请求预览和状态切换合计 87 ms，远低于三秒。但它不包含 Core File Kit 读取、ArkTS 到 ArkWeb 的字符串传递、进程调度和真机存储，所以文章只把它写成 Web 回归。G1 模拟器曾测得 10 MiB 整链 345 ms，Release 真机 P95 仍待 G4 质量专项。

一千文件语料怎样避免假快

如果 1000 个文件都含查询词，SearchService 达到 500 结果上限后会提前停止扫描。此时测试可能很快，却不能证明工作区能遍历 1000 个文档。新用例只让最后一个 report-0999.md 包含“唯一压力命中”，前 999 个只有普通内容。要获得唯一结果，控制器必须走完整个集合。

for (let index = 0; index < 1000; index += 1) {
  const sequence = index.toString().padStart(4, '0');
  const content = index === 999
    ? '# 压力文档\n\n唯一压力命中\n'
    : `# 文档 ${sequence}\n\n普通内容\n`;
  await writeRawText(`${searchWorkspace}/report-${sequence}.md`, content);
}

用例断言 documentsDiscovered=1000、documentsScanned=1000、documentsSkipped=0、results.length=1 和结果路径。任何文件被扩展名过滤、读取失败、TaskPool 异常或提前截断都会留下不同数字。

语料位于应用测试沙箱，不进入 Git。beforeEach 和 afterEach 递归清理目录，测试中断后的下一轮也会先清理。这样既避免仓库膨胀，又保证同名旧文件不会污染结果。

搜索 419 毫秒意味着什么

MateBook Pro 2in1 模拟器日志记录 1000 文件全文搜索 419 ms、快速打开 50 ms。完整用例包含 1000 次小文件写入、两轮文档收集和断言，耗时 1556 ms；完整十项 ohosTest 为 1649 ms。

419 ms 可以证明当前模拟器环境下没有明显的秒级阻塞，但不能直接证明 UI 输入 P95。WorkspaceSearchController 的单篇正则匹配放到 TaskPool，目录枚举和读取仍由异步 Core File Kit 完成；真正的用户体验还取决于结果面板渲染、取消手势、磁盘缓存与工作区目录层次。

更不能据此宣称比 Typora、Obsidian 或 VS Code 快 20%。竞品必须使用相同文件数量、层级、文件大小、查询位置、冷/热缓存和设备。没有这些元数据，两个毫秒数字不能比较。

快速打开与全文搜索为何分测

全文搜索读取正文并执行查询，快速打开只收集文件元数据并在 TaskPool 中模糊排序。它们共享工作区收集器，却有不同成本和产品任务。把快速打开当成全文搜索性能，会得到过度乐观结果；把全文搜索时间当成文件名跳转，也会低估桌面效率。

用例对 report-0999 执行 quickOpen，第一结果必须为 report-0999.md，耗时上限 5 秒。当前实测 50 ms。最近文件权重数组传空，避免旧会话把目标提前加权；这样测的是文件名精确前缀与路径排序，而不是持久化历史。

未来竞品实测应分别记录“打开已知文件名”和“查找正文中的未知文件”。两个任务的操作数、认知成本和结果质量不同，不能用一个平均数掩盖。

应用内部设备证据

下图来自最终 G3-09/G3-10 Debug HAP 在 HarmonyOS MateBook Pro 2in1 模拟器中的真实 OhMarkdown 主窗口。1280 vp 预算下，多标签、停靠侧栏、分栏预览、工具栏和状态栏同时存在，没有重叠。1000 文件压力使用同一应用服务和同一测试 HAP，不是 Node.js 对纯函数的替代跑分。

原生十项回归覆盖什么

ohosTest 现在包含：未保存正文分享快照、BOM/CRLF 字节一致、混合换行归一、失败保存备份恢复、文件指纹、图片完整落盘/重名/三模式、基础搜索/取消、1000 文件压力、中文链接补全/越界拒绝和 UTF-16 标题偏移。

它们共同覆盖文件事实来源和原生服务，但不点击所有 ArkUI 组件。右键、拖放、自由窗口和系统对话框仍由设备操作用例覆盖；Web 右键与渲染由 Playwright 覆盖。测试分层不是重复，而是让每个环境验证自己能观察的事实。

最终 Debug HAP 为 8,542,985 字节，SHA-256 f88af05e83a411f7230927c527d0b1fa74243049a6e2261fe9d11c7e544e8655；ohosTest HAP 为 9,315,428 字节，SHA-256 ca0400141d46d51e3698a2d9187fe70359a6b1f8e1018eab9f4c36e0fd3c5571。哈希把测试结果绑定到明确产物。

性能断言为什么要有宽松硬上限

10 MiB Web 用例断言 3 秒，直接对应 PRD；1000 文件搜索使用 10 秒，快速打开使用 5 秒。这些上限不是当前性能目标，而是 CI 退化保险。当前结果比上限快很多，给不同机器和模拟器调度留下余量，避免把偶发系统负载当成产品回归。

精细性能门槛应在固定 Release 真机上统计 P50/P95，并预热/冷启分组。把本机 87 ms 直接变成 CI 的 100 ms 断言，会产生脆弱测试；把上限设成一分钟又无法拦截算法退化。阶段门禁使用产品预算或数量级边界，专项基准再使用统计分布。

测试数据不能泄露真实正文

压力语料完全合成，只包含序号和固定中文查询。日志记录文件数量、耗时和结果路径中的测试名，不记录用户正文、真实路径或文件名。生产性能日志也只记录读取字节、字符数与耗时。

真实封闭测试的数据字典更严格：不上传正文、文件名、路径、链接或图片；崩溃附件可查看、关闭和清理。工程性能用例先遵守同样原则，可以减少后续“为了测量再重写遥测”的隐私债务。

全量门禁的真实结果

最终 verify-local 中 Vite 单 HTML约 7.67 MB，gzip 约 3.43 MB；Playwright 44/44；Debug HAP 和 ArkTS UnitTestBuild 成功；diff check 通过。ohosTest 单独构建安装后 10/10，Failure 与 Error 为 0。

这里没有把首次错误语料隐藏。第一版 10 MiB 用例只生成约 9.32 MiB，断言失败；修复生成公式后定向 1/1 和全量 44/44 均通过。保留失败原因能证明测试确实约束样本，而不是永远成功的装饰。

仍未完成的 Beta 退出条件

第一，G3-08 仍缺系统 PDF 服务、兼容 Markdown 分享接收方和 HTML/PNG 独立查看。第二，PRD 要求 50-100 人封闭测试，真实参与者尚未开始。第三，核心任务领先 20% 尚无统一竞品数据。第四，鸿蒙 PC 真机、物理触控板、系统字体与输入法矩阵仍缺。第五，1000 次强杀恢复不能用一次 ohosTest代替。

因此 G3-10 状态是“进行中”，不是“完成”。工程团队可以继续准备竞品语料、真机脚本和匿名反馈表，但不能把模拟器自动化换算成用户满意度、崩溃率或留存。

对产品优势的实际贡献

一千文件搜索把“工作区搜索存在”推进为“指定规模下准确且有界”；十兆字节把“大文档模式存在”推进为“精确样本三秒门禁”；哈希与统一脚本让设备证据可追溯。这些能力不会出现在营销标题里，却决定编辑器在真实项目中是否可信。

当前工作区搜索可以保持记分卡 3 分，因为功能、失败路径和模拟器规模证据完整。升到 4 分仍需要真机和竞品中位数。10 MiB 仍为 2 分，因为本轮新增的是 Web 自动化，既有模拟器数据也不是最终 Release 真机。这种保守评分能防止产品在开发期提前消费信誉。

下一步质量工程

后续先固定竞品版本、语料哈希、设备和计时边界，再执行打开单文件、1000 文件工作区、图片、冲突、恢复、中文输入、复杂导出和全键盘任务。真机性能要记录主进程与 ArkWeb 进程组 PSS、输入 P95、搜索取消后的 CPU 和冷/热缓存。

恢复专项需要可重复强杀脚本与每轮内容校验，任何数据丢失立即停止功能扩展。封闭测试则以真实任务成功率和缺陷闭环为主，不把自动化通过数当作用户完成率。

结论

鸿蒙 PC Markdown 编辑器的 Beta 质量门禁必须同时回答“有没有”“规模下是否准确”“失败会不会污染”“结论能否复现”。OhMarkdown 在 G3-10 第一纵切中增加精确 10 MiB Web 用例和 1000 文件模拟器压力，用统一脚本串联 44 项 Web、10 项原生、HAP 构建和 diff 检查。

当前 10 MiB Web 加载 87 ms，1000 文件搜索 419 ms，快速打开 50 ms，所有结果都绑定代码、环境和 HAP 哈希。它们足以证明内部质量基线继续向前，但不足以替代真机、竞品和真实用户。把这个边界写清楚，本身就是一个长期产品的质量能力。