鸿蒙 PC Markdown 编辑器第二阶段工程复盘：从可用原型到 Alpha 基线
第二阶段的工程目标不是继续堆按钮，而是把 G1技术纵切变成可持续日常使用的 Alpha基线：异常退出能恢复，文件格式不被静默改变，工作区与多标签不丢未保存内容，搜索和大纲进入高频路径，预览、主题和测试具备稳定边界。
本文复盘 OhMarkdown G2-01至 G2-08当前进展、关键决策、缺陷修复和未完成闸门。https://gitcode.com/VON-/codex_md_oh
阶段起点
G1证明 ArkUI外壳、离线 ArkWeb/CodeMirror、Bridge、单文件、导出和2in1模拟器可行。遗留风险是单文档状态、崩溃草稿、BOM/CRLF、安全保存、工作区、多标签和质量闸门。
G2把顺序定为：计划闸门、恢复、无损保存、工作区、多标签、编辑效率、渲染外观、质量基线、Alpha评审。数据安全先于便利功能，避免在不可靠文件模型上继续扩展。
G2-02 恢复闭环
Web按1.5秒节流发送最新正文和 revision，原生限制五兆、写入应用沙箱 AtomicFile。单写入者队列合并中间版本，generation防止保存清理后旧异步写入复活。
ts
function scheduleRecoverySnapshot(): void {
if (!pendingDirty || largeDocumentMode) {
window.clearTimeout(recoveryTimer);
recoveryTimer = undefined;
return;
}
if (recoveryTimer !== undefined) {
return;
}
recoveryTimer = window.setTimeout(
flushRecoverySnapshot,
RECOVERY_SNAPSHOT_INTERVAL_MILLISECONDS
);
}启动读取记录并校验版本、长度、格式；用户选择 Recover或 Discard。恢复后 forcedDirty保持星号，直到真实保存。模拟器 force-stop后恢复通过。
边界：五兆以上不周期全文恢复，完整多标签恢复未实现。工程结论限定为活动常规文档 RPO不超过2秒的最小闭环。
AtomicFile 的实际缺陷
初版恢复写流使用 write()后立即 finishWrite()，设备字节校验暴露提交时序问题。修复为等待 writeStream.end(payload, 'utf-8', callback)后 finish，再 stat比较 UTF-8预期字节。
这次缺陷说明 API名称看似正确不等于流已收口。恢复功能必须用故障与字节测试，而不是只看 JSON文件存在。
G2-03 文本保真
抽取 DocumentFormatService，定义 BOM与 LF、CRLF、MIXED、NONE。读取先检测 EF BB BF，内存移除 U+FEFF但保存 format；线性扫描完整正文检测换行。
序列化 LF先把所有终止符统一为 \n；CRLF先统一 LF再扩展，避免 \r\r\n。Mixed修改后询问 LF/CRLF/取消。ohosTest证明 BOM+CRLF未编辑保存字节一致，Mixed可明确归一。
用户 URI覆盖前把旧正文和格式原子备份到沙箱，写入验证字节、truncate、fsync。目标故障后旧版本可恢复。
外部冲突与保存基线
打开时保存 persisted正文与 format，保存前重读磁盘；正文或格式变化都拒绝覆盖。保存请求固定 CodeMirror Text和 revision，期间继续输入则磁盘成功但当前仍 Modified。
保存并关闭不在按钮点击时删除标签，而在 finally确认目标仍活动且 dirty false。选择器取消、Mixed取消、冲突和写失败都保留会话。这些状态机细节比"有 Save按钮"更接近专业编辑器。
G2-04 工作区
系统 FolderSelection建立授权，listFile只读直接子项，每层最多2000，目录与 Markdown过滤、目录优先排序。树用带 depth的扁平可见数组，展开插入直接子项，折叠删除连续后代。
模拟器首次把完整 URI传 listFile报 No such file，修复为结构化 URI取 path枚举，再保留原 URI构造子项。这是平台实测带来的关键修正。
当前无最近工作区、刷新和监听，2000项缺设备规模测试。按 G2-04纵切，授权、一级树、按需展开和树内打开完成。
G2-05 多标签
原生 DocumentSession保存 id、URI、正文、persisted基线、format、revision、dirty、wordCount和大文档模式。Web为每 session保存完整 EditorState、保存基线和恢复版本。
ts
private async activateDocumentSession(
sessionId: string
): Promise<void> {
const targetSession = this.documentSessions.find(
(session: DocumentSession): boolean =>
session.id === sessionId
);
if (!targetSession) {
return;
}
await this.captureActiveDocumentSession();
this.applyDocumentSession(targetSession);
await this.activateEditorSession(targetSession);
}切换遵循先捕获当前、应用目标、激活 EditorState；清除旧 Bridge/恢复定时器，防止延迟消息归错标签。打开相同 URI激活已有会话，干净空白标签可复用。
十二标签上限控制内存；脏标签关闭有取消、放弃、保存；最后一个关闭后创建空白会话。Playwright和模拟器验证正文、历史与关闭分支。
runJavaScript 返回值缺陷
多标签捕获和 HTML导出发现 ArkWeb字符串结果经过 JSON编码，直接使用会保留外层引号与 \n。新增 decodeJavaScriptString用 JSON.parse恢复，失败回退原值。
数字搜索结果用 parseInt，布尔打印结果比较 'true'。反向参数全部 JSON.stringify。这一缺陷推动 Bridge从方便脚本调用升级为正式类型协议。
G2-06 编辑效率
查找支持大小写、整词、正则、前后循环；替换支持当前、全部和捕获组。Replace All一次 CodeMirror transaction，整体撤销。零宽正则暂拒绝，非法正则当前与零匹配仍需更明确错误。
ArkUI搜索面板 Ctrl+F后延迟聚焦。大纲服务提取 ATX、Setext，忽略反引号/波浪号围栏，保存 UTF-16 offset和行号。点击后 CodeMirror检查边界、切回源码、设置选区与滚动。
自动化与模拟器验证两个匹配、两个标题和跳转。工作区全文搜索不属于本纵切。
G2-07 渲染与外观
固定任务列表插件2.1.1，补齐表格、删除线、自动链接、只读任务项。所有 markdown-it输出经过 DOMPurify，链接不在 ArkWeb直接导航。
分栏使用双向比例同步，动画帧锁阻止递归，用户可关闭。窄于760变上下布局。
主题使用 ArkUI base/dark资源，EntryAbility在创建、配置更新和前台写 AppStorage，WorkspaceShell观察后显式调用 Web setTheme。初测只靠媒体查询导致外壳暗、Web白，显式 Bridge修复后完整深色通过。
G2-08 质量基线
建立 CommonMark、GFM、大纲和安全四类 fixture；Web自动化扩展为20项；ohosTest为4项；Debug、Release和 UnitTestBuild成功；本机统一脚本与 GitCode配置入库；内部试用记录定义。
Release unsigned HAP为1006605字节，SHA-256 6d08d725bcb219ae97508281477cedb40d766d6860d7062e14d873f30322e31c。
远程 GitCode Runner首次结果尚未确认，内部试用0人0天。因此 G2-08保持进行中，不把工程准备冒充外部通过。
测试数字的含义
20/20说明已写 Web契约在 Chromium环境通过；4/4说明文档字节、故障备份和大纲在目标 ArkTS测试通过；构建成功说明 API 24工具链兼容；模拟器截图说明系统交互进入2in1。
这些数字不证明完整 CommonMark套件、真机 P95、所有 provider和长期稳定。复盘同时记录剩余风险，避免完成感掩盖未知。
性能结果
1MiB总加载83ms，10MiB345ms，满足1秒/3秒预算。1MiB完整进程组 PSS 324.7MiB，高于250MiB目标29.9%；10MiB396.4MiB。加载优秀，内存仍是明确缺口。
五兆以上进入轻量 CodeMirror、禁预览/字数/打印/周期恢复。修复前10MiB连续撤销曾 LowMemoryKill，修复后相同路径未新增异常，但需要重复真机压力。
架构取舍
保持单 entry模块，不提前拆 HAR；服务只抽取 Recovery、DocumentFormat、Workspace、Session和 Outline等真实边界；不引入数据库、事件总线和插件框架。
ArkUI负责系统、文件、工作台，ArkWeb负责高频编辑与渲染。高频滚动不跨 Bridge，全文只在保存/恢复/切换传递。复杂度增加集中在数据安全和状态归属，而不是通用框架。
做得正确的顺序
先恢复再无损保存，先工作区再多标签，先会话隔离再搜索大纲，最后渲染主题和质量。若先做多标签 UI而没有 DocumentFormat与保存状态，每个标签都会复制同样数据风险。
每步有报告、用例和证据，问题在对应纵切收口。阶段状态只允许进行中、完成、受阻，未通过不提前标完成。
没有完成的内容
远程 CI首跑；10人连续7天；G2-09 Alpha评审；鸿蒙 PC真机多窗口/触控板；完整多标签恢复；文件监听与刷新；2000项目录压力；内存正式目标；签名发布。
这些不能靠技术文章数量消除。文章可以总结实现和方法，外部时间/设备条件仍需真实执行。
鸿蒙 PC 当前工程基线
下图展示第二阶段形成的工作台：文件面板、标签、编辑器、模式和状态栏已进入真实2in1应用。
专项证据还包括恢复、字节格式、工作区、多标签、搜索、大纲、分栏和深色。完整画面不是最终 Alpha通过徽章。
下一步
确认 GitCode流水线平台配置并取得首个绿色 job；组织十名参与者按匿名方案启动七天试用；P0立即冻结修复；满足后更新试用数据、质量报告和本文最终结论；执行 G2-09并形成 Beta范围。
工程侧同时准备真机性能、窗口矩阵和内存优化，但不让新功能打断外部闸门。
当前阶段结论
截至2026-07-18，G2-01至 G2-07完成，G2-08进行中，G2-09未开始。第二阶段核心工程主体已经建立，但阶段尚未正式结束。
这不是模糊的"差不多完成"：已完成内容有测试和设备证据，未完成内容有明确数字0/10、0/7和远程 job缺口。
对后续研发方式的影响
G2证明每个用户可见能力都应同时设计状态归属、失败路径和证据。Beta图片粘贴不能只插入语法，还要处理资源目录、冲突、撤销和失败残留；全文搜索不能只返回列表，还要处理索引版本、未保存缓冲区和取消；外部链接不能只调用浏览器，还要做协议白名单和隐私提示。
服务抽取也应继续由风险驱动。已有第二调用方或需要独立设备测试时抽取；只有一个简单入口时保留局部，不为"架构完整"增加仓储层。重大取舍写 ADR，阶段步骤继续更新计划、进度、测试报告和证据。
性能与安全作为功能验收的一部分：新渲染插件必须测包体、预览耗时和 DOM净化；新会话能力必须测总内存和恢复；新网络能力默认关闭并说明外发内容。G2建立的门禁不是阶段文档负担，而是 Beta扩大范围时防止质量倒退的基础设施。
产品层面的收获
"优于其他产品"在本阶段被转换为具体标准：未编辑保存字节一致、恢复RPO明确、取消不会丢缓冲区、分栏主题完整、错误可恢复、测试状态不夸大。它不是通过同时实现 Obsidian插件、VS Code命令和 Typora渲染来达成。
PC优先也从宽屏布局变成键盘焦点、自由窗口断点、系统选择器、触控板滚动、状态栏格式和多标签生命周期。后续竞品对比应使用这些标准任务与量化结果，而不是功能表勾选数量。
结语
第二阶段把 OhMarkdown从可输入的纵切推进到有恢复、文本保真、工作区、多标签、搜索大纲、GFM分栏、系统主题和质量脚本的 Alpha工程基线。过程中修复了 AtomicFile流提交、URI/path、ArkWeb JSON返回和显式主题传播等真实平台问题。
一个要做大的鸿蒙 PC Markdown编辑器不仅要持续增加能力，还要能拒绝提前完成。当前正确动作是完成外部质量闸门，再用同一套证据纪律进入 Beta。